Сообщение Re[2]: HTML-based верстка - может ли помереть? от 18.10.2022 10:54
Изменено 18.10.2022 17:36 Михаил Романов
Re[2]: HTML-based верстка - может ли помереть?
Здравствуйте, Буравчик, Вы писали:
Б>Что-то я даже XAML-стандарта не нашел
Стандарта вроде и не оформляли.
Но есть более-менее формальная спецификация https://www.microsoft.com/en-us/download/details.aspx?id=19600.
Б>Чем XAML лучше HTML?
Сложно сказать.
Наверное, будет правильнее сказать, что XAML, это не язык разметки UI, это XML-based язык для сериализации дерева объектов, с некоторыми своими особенностями.
Например (навскидку, что помню):
— синтаксис для свойств допускает указание свойств как атрибутов тэгов и в специальной нотации элементов:
— описан синтаксис для markup extensions в атрибутах
В той же спецификации задаются базовые типы, которые поддерживаются "из коробки", а также правила инстанцирования, того, что записано в виде XAML-документа.
В пользу того, что в целом XAML это не только для UI? можно привести примеры использования XAML в MsBuild (для описания правил разметки самого MsBuild), в WorkflowFoundation (насчет 4 версии не знаю, а в 3 и 3.5 для сериализации использовался XAML).
То, что XAML в WPF используется как язык разметки UI, это скорее следствие того, что в WPF так строится представление — в виде дерева контролов (хотя у кого это не так, я вот с ходу и не скажу...). Поэтому он там смотрится вполне органично.
Ну а если вернутся к исходному вопросу — чем лучше?
Если брать изначальный HTML, то вы манипулируете куда более низкоуровневыми понятиями и привязанными к тексту (параграф, список, ... ), тогда как XAML и ему подобные языки оперируют компонентами (Slider, tab, button).
Но, сейчас на HTML так пишут разве что для самых нетребовательных сайтов. Остальные же, там где нужен сложный интерфейс, даже если не используют React/Vue, применяют что-то типа Web Components (не те, которые в стандарте, а что-то из серии — например, у MS это FAST для Fluent UI на "чистом" HTML (да, там идет препроцессинг HTML, поэтому "чистый" я и взял в кавычки, чем это отличает от того же XAML?)
Приведу еще один пример, почему HTML и XAML сложно сравнивать.
Многие указывают на, то что механизм стилизации в XAML просто ужасен по сравнению с CSS. И спорить сложно если смотреть вот на такое:
В сравнении с чем-то таким (примеры не совсем эквивалентны, но просто мне было лень да и некогда вспоминать WPF и разбираться с CSS):
Возражать действительно сложно, но...
Во-первых, если взглянуть на первые части обоих примеров, то получается примерно баш на баш (с точностью до избыточности разметки XML)
Во-вторых, во второй части для Foreground идет очень громоздкое описание градиентной кисти, но, честно говоря, я не вижу почему бы для представления конкретно градиентов нельзя было бы сделать специальный markup extensions. Возможно, сами MS посчитали, что это редкий сценарий и не стали заморачиваться, а из сторонних разработчиков... ну может просто я не нашел.
В-третьих, строго говоря CSS — это не HTML, поэтому теоретически CSS можно было бы попытаться использовать и для WPF благо в той же Avalonia сделали поддержку селекторов в стиле CSS, а всё остальное — это маппинг конкретных свойств в CSS на аналоги в WPF (1-в-1 всё равно не получится, правда). Т.е. скорее всего бы получилось, но опять же никто, похоже, не видит смысла, ведь придется поддерживать еще один язык (а со стилями в том же WPF большая часть разработчиков предпочитает не связываться вообще и использовать стандартные, т.е. нужно будет — единицам).
Б>Что-то я даже XAML-стандарта не нашел
Стандарта вроде и не оформляли.
Но есть более-менее формальная спецификация https://www.microsoft.com/en-us/download/details.aspx?id=19600.
Б>Чем XAML лучше HTML?
Сложно сказать.
Наверное, будет правильнее сказать, что XAML, это не язык разметки UI, это XML-based язык для сериализации дерева объектов, с некоторыми своими особенностями.
Например (навскидку, что помню):
— синтаксис для свойств допускает указание свойств как атрибутов тэгов и в специальной нотации элементов:
<MyElem Width="42" Quality="High">
<MyElem.Bar>
<Child Less="More" />
</MyElem.Bar>
</MyElem>— описан синтаксис для markup extensions в атрибутах
<Button Background="{Binding Path=ColorName}" Width="150" Height="30">
I am bound to be RED!
</Button>В той же спецификации задаются базовые типы, которые поддерживаются "из коробки", а также правила инстанцирования, того, что записано в виде XAML-документа.
В пользу того, что в целом XAML это не только для UI? можно привести примеры использования XAML в MsBuild (для описания правил разметки самого MsBuild), в WorkflowFoundation (насчет 4 версии не знаю, а в 3 и 3.5 для сериализации использовался XAML).
То, что XAML в WPF используется как язык разметки UI, это скорее следствие того, что в WPF так строится представление — в виде дерева контролов (хотя у кого это не так, я вот с ходу и не скажу...). Поэтому он там смотрится вполне органично.
Ну а если вернутся к исходному вопросу — чем лучше?
Если брать изначальный HTML, то вы манипулируете куда более низкоуровневыми понятиями и привязанными к тексту (параграф, список, ... ), тогда как XAML и ему подобные языки оперируют компонентами (Slider, tab, button).
Но, сейчас на HTML так пишут разве что для самых нетребовательных сайтов. Остальные же, там где нужен сложный интерфейс, даже если не используют React/Vue, применяют что-то типа Web Components (не те, которые в стандарте, а что-то из серии — например, у MS это FAST для Fluent UI на "чистом" HTML (да, там идет препроцессинг HTML, поэтому "чистый" я и взял в кавычки, чем это отличает от того же XAML?)
Приведу еще один пример, почему HTML и XAML сложно сравнивать.
Многие указывают на, то что механизм стилизации в XAML просто ужасен по сравнению с CSS. И спорить сложно если смотреть вот на такое:
<Window.Resources>
<!-- .... other resources .... -->
<!--A Style that affects all TextBlocks-->
<Style TargetType="TextBlock">
<Setter Property="HorizontalAlignment" Value="Center" />
<Setter Property="FontFamily" Value="Comic Sans MS"/>
<Setter Property="FontSize" Value="14"/>
</Style>
<!--A Style that extends the previous TextBlock Style with an x:Key of TitleText-->
<Style BasedOn="{StaticResource {x:Type TextBlock}}"
TargetType="TextBlock"
x:Key="TitleText">
<Setter Property="FontSize" Value="26"/>
<Setter Property="Foreground">
<Setter.Value>
<LinearGradientBrush StartPoint="0.5,0" EndPoint="0.5,1">
<LinearGradientBrush.GradientStops>
<GradientStop Offset="0.0" Color="#90DDDD" />
<GradientStop Offset="1.0" Color="#5BFFFF" />
</LinearGradientBrush.GradientStops>
</LinearGradientBrush>
</Setter.Value>
</Setter>
</Style>
</Window.Resources>В сравнении с чем-то таким (примеры не совсем эквивалентны, но просто мне было лень да и некогда вспоминать WPF и разбираться с CSS):
p {
font-size: 14px;
font-family: Comic Sans MS;
text-align: center;
}
.text_title {
font-size: 26px;
background: linear-gradient(#90DDDD, #5BFFFF);
}Возражать действительно сложно, но...
Во-первых, если взглянуть на первые части обоих примеров, то получается примерно баш на баш (с точностью до избыточности разметки XML)
Во-вторых, во второй части для Foreground идет очень громоздкое описание градиентной кисти, но, честно говоря, я не вижу почему бы для представления конкретно градиентов нельзя было бы сделать специальный markup extensions. Возможно, сами MS посчитали, что это редкий сценарий и не стали заморачиваться, а из сторонних разработчиков... ну может просто я не нашел.
В-третьих, строго говоря CSS — это не HTML, поэтому теоретически CSS можно было бы попытаться использовать и для WPF благо в той же Avalonia сделали поддержку селекторов в стиле CSS, а всё остальное — это маппинг конкретных свойств в CSS на аналоги в WPF (1-в-1 всё равно не получится, правда). Т.е. скорее всего бы получилось, но опять же никто, похоже, не видит смысла, ведь придется поддерживать еще один язык (а со стилями в том же WPF большая часть разработчиков предпочитает не связываться вообще и использовать стандартные, т.е. нужно будет — единицам).
Re[2]: HTML-based верстка - может ли помереть?
Здравствуйте, Буравчик, Вы писали:
Б>Что-то я даже XAML-стандарта не нашел
Стандарта вроде и не оформляли.
Но есть более-менее формальная спецификация https://www.microsoft.com/en-us/download/details.aspx?id=19600.
Б>Чем XAML лучше HTML?
Сложно сказать.
Наверное, будет правильнее сказать, что XAML, это не язык разметки UI, это XML-based язык для сериализации дерева объектов, с некоторыми своими особенностями.
Например (навскидку, что помню):
— синтаксис для свойств допускает указание свойств как атрибутов тэгов и в специальной нотации элементов:
— описан синтаксис для markup extensions в атрибутах
В той же спецификации задаются базовые типы, которые поддерживаются "из коробки", а также правила инстанцирования, того, что записано в виде XAML-документа.
В пользу того, что в целом XAML это не только для UI можно привести примеры использования XAML в MsBuild (для описания правил разметки самого MsBuild), в WorkflowFoundation (насчет 4 версии не знаю, а в 3 и 3.5 для сериализации использовался XAML).
То, что XAML в WPF используется как язык разметки UI, это скорее следствие того, что в WPF так строится представление — в виде дерева контролов (хотя у кого это не так, я вот с ходу и не скажу...). Поэтому он там смотрится вполне органично.
Ну а если вернутся к исходному вопросу — чем лучше?
Если брать изначальный HTML, то вы манипулируете куда более низкоуровневыми понятиями и привязанными к тексту (параграф, список, ... ), тогда как XAML и ему подобные языки оперируют компонентами (Slider, tab, button).
Но, сейчас на HTML так пишут разве что для самых нетребовательных сайтов. Остальные же, там где нужен сложный интерфейс, даже если не используют React/Vue, применяют что-то типа Web Components (не те, которые в стандарте, а что-то из серии — например, у MS это FAST для Fluent UI на "чистом" HTML (да, там идет препроцессинг HTML, поэтому "чистый" я и взял в кавычки, чем это отличает от того же XAML?)
Приведу еще один пример, почему HTML и XAML сложно сравнивать.
Многие указывают на, то что механизм стилизации в XAML просто ужасен по сравнению с CSS. И спорить сложно если смотреть вот на такое:
В сравнении с чем-то таким (примеры не совсем эквивалентны, но просто мне было лень да и некогда вспоминать WPF и разбираться с CSS):
Возражать действительно сложно, но...
Во-первых, если взглянуть на первые части обоих примеров, то получается примерно баш на баш (с точностью до избыточности разметки XML)
Во-вторых, во второй части для Foreground идет очень громоздкое описание градиентной кисти, но, честно говоря, я не вижу почему бы для представления конкретно градиентов нельзя было бы сделать специальный markup extensions. Возможно, сами MS посчитали, что это редкий сценарий и не стали заморачиваться, а из сторонних разработчиков... ну может просто я не нашел.
В-третьих, строго говоря CSS — это не HTML, поэтому теоретически CSS можно было бы попытаться использовать и для WPF благо в той же Avalonia сделали поддержку селекторов в стиле CSS, а всё остальное — это маппинг конкретных свойств в CSS на аналоги в WPF (1-в-1 всё равно не получится, правда). Т.е. скорее всего бы получилось, но опять же никто, похоже, не видит смысла, ведь придется поддерживать еще один язык (а со стилями в том же WPF большая часть разработчиков предпочитает не связываться вообще и использовать стандартные, т.е. нужно будет — единицам).
Б>Что-то я даже XAML-стандарта не нашел
Стандарта вроде и не оформляли.
Но есть более-менее формальная спецификация https://www.microsoft.com/en-us/download/details.aspx?id=19600.
Б>Чем XAML лучше HTML?
Сложно сказать.
Наверное, будет правильнее сказать, что XAML, это не язык разметки UI, это XML-based язык для сериализации дерева объектов, с некоторыми своими особенностями.
Например (навскидку, что помню):
— синтаксис для свойств допускает указание свойств как атрибутов тэгов и в специальной нотации элементов:
<MyElem Width="42" Quality="High">
<MyElem.Bar>
<Child Less="More" />
</MyElem.Bar>
</MyElem>— описан синтаксис для markup extensions в атрибутах
<Button Background="{Binding Path=ColorName}" Width="150" Height="30">
I am bound to be RED!
</Button>В той же спецификации задаются базовые типы, которые поддерживаются "из коробки", а также правила инстанцирования, того, что записано в виде XAML-документа.
В пользу того, что в целом XAML это не только для UI можно привести примеры использования XAML в MsBuild (для описания правил разметки самого MsBuild), в WorkflowFoundation (насчет 4 версии не знаю, а в 3 и 3.5 для сериализации использовался XAML).
То, что XAML в WPF используется как язык разметки UI, это скорее следствие того, что в WPF так строится представление — в виде дерева контролов (хотя у кого это не так, я вот с ходу и не скажу...). Поэтому он там смотрится вполне органично.
Ну а если вернутся к исходному вопросу — чем лучше?
Если брать изначальный HTML, то вы манипулируете куда более низкоуровневыми понятиями и привязанными к тексту (параграф, список, ... ), тогда как XAML и ему подобные языки оперируют компонентами (Slider, tab, button).
Но, сейчас на HTML так пишут разве что для самых нетребовательных сайтов. Остальные же, там где нужен сложный интерфейс, даже если не используют React/Vue, применяют что-то типа Web Components (не те, которые в стандарте, а что-то из серии — например, у MS это FAST для Fluent UI на "чистом" HTML (да, там идет препроцессинг HTML, поэтому "чистый" я и взял в кавычки, чем это отличает от того же XAML?)
Приведу еще один пример, почему HTML и XAML сложно сравнивать.
Многие указывают на, то что механизм стилизации в XAML просто ужасен по сравнению с CSS. И спорить сложно если смотреть вот на такое:
<Window.Resources>
<!-- .... other resources .... -->
<!--A Style that affects all TextBlocks-->
<Style TargetType="TextBlock">
<Setter Property="HorizontalAlignment" Value="Center" />
<Setter Property="FontFamily" Value="Comic Sans MS"/>
<Setter Property="FontSize" Value="14"/>
</Style>
<!--A Style that extends the previous TextBlock Style with an x:Key of TitleText-->
<Style BasedOn="{StaticResource {x:Type TextBlock}}"
TargetType="TextBlock"
x:Key="TitleText">
<Setter Property="FontSize" Value="26"/>
<Setter Property="Foreground">
<Setter.Value>
<LinearGradientBrush StartPoint="0.5,0" EndPoint="0.5,1">
<LinearGradientBrush.GradientStops>
<GradientStop Offset="0.0" Color="#90DDDD" />
<GradientStop Offset="1.0" Color="#5BFFFF" />
</LinearGradientBrush.GradientStops>
</LinearGradientBrush>
</Setter.Value>
</Setter>
</Style>
</Window.Resources>В сравнении с чем-то таким (примеры не совсем эквивалентны, но просто мне было лень да и некогда вспоминать WPF и разбираться с CSS):
p {
font-size: 14px;
font-family: Comic Sans MS;
text-align: center;
}
.text_title {
font-size: 26px;
background: linear-gradient(#90DDDD, #5BFFFF);
}Возражать действительно сложно, но...
Во-первых, если взглянуть на первые части обоих примеров, то получается примерно баш на баш (с точностью до избыточности разметки XML)
Во-вторых, во второй части для Foreground идет очень громоздкое описание градиентной кисти, но, честно говоря, я не вижу почему бы для представления конкретно градиентов нельзя было бы сделать специальный markup extensions. Возможно, сами MS посчитали, что это редкий сценарий и не стали заморачиваться, а из сторонних разработчиков... ну может просто я не нашел.
В-третьих, строго говоря CSS — это не HTML, поэтому теоретически CSS можно было бы попытаться использовать и для WPF благо в той же Avalonia сделали поддержку селекторов в стиле CSS, а всё остальное — это маппинг конкретных свойств в CSS на аналоги в WPF (1-в-1 всё равно не получится, правда). Т.е. скорее всего бы получилось, но опять же никто, похоже, не видит смысла, ведь придется поддерживать еще один язык (а со стилями в том же WPF большая часть разработчиков предпочитает не связываться вообще и использовать стандартные, т.е. нужно будет — единицам).