5 ms·

No more direct href links from SVG document? This is unwelcome change.

lucideer 10y ago
Where are you seeing this? Is this not what you're referring to https://svgwg.org/svg2-draft/linking.html#AElementHrefAttribute https://svgwg.org/svg2-draft/linking.html#AElementHrefAttrib... ?
rspeer 10y ago
They're deprecating "a xlink:href" and adding "a href". Sounds good to me. I never had any idea why it had to be "a xlink:href" except that this was designed when someone thought XML namespaces were a good idea.
- Mikhail_Edoshin 10y ago
  XML namespaces still are a good idea.
  - rspeer 10y ago
    What problem do they solve? (Problems that were created by XML in the first place don't count.)
    - Mikhail_Edoshin 10y ago
      With XML namespaces independent development teams can freely design their own structures and interfaces and then mix them in a very granular manner without danger of name clash. This promotes design and reuse of specialized mini-language with exact precise semantic. xlink:href is better than plain href because plain href is an informal convention, while xlink:href is code reuse.
      - rspeer 10y ago
        You're spinning an XML fantasy. XML is not good at describing structures or interfaces. It does not have precise semantics. The semantics of XML are so vague that you can't even tell whether whitespace is significant when parsing it. XML describes marked-up text. And yet it's awkward enough that it's not even used anymore for the most common case of marked-up text (HTML), which is why SVG is evolving to be more like HTML now.
        ygra 10y ago
        SVG is evolving to be more like HTML because browsers suck at embedded XML content in HTML tag soup.
        Mikhail_Edoshin 10y ago
        The semantic of a computer language (and a markup language in particular) is what the code does with it. Sometimes the code uses whitespace and sometimes it doesn't; XML doesn't enforce either way and leaves this up to the app. When necessary you can explicitly mark your preference in different parts of the tree with the 'xml:space' attribute. This attribute has precise and unambiguous semantic. It is also another example of why namespaces are important: it's a universal attribute that can be used with any XML document, by the virtue of namespaces it will never conflict with anything, it has a clear and small area of responsibility so any software vendor can easily implement it, you don't need to invent your own conventions or whatever, just reuse it. By comparison, HTML has almost no semantic. You have no idea what the code (which code, by the way?) is going to do with your 'article' tags or tell exactly how 'nav' is different from 'menu'; this spins endless debate about which tag to use. I remember how people argued that using 'dl' for figures with captions was, you know, "semantic markup" :) This is not semantic markup. Semantic markup would be things like <date:timestamp value="..." /> that a browser would render in my timezone or <chess:position move="white">...</chess:position> to describe a position on a chessboard so that a search engine could find similar positions or chess parties where this position has occurred. This is semantic markup and this could be semantic Web. And to make this happen we need to be able to develop small and clearly specified mini-languages with precise semantic (=computer instructions) and then mix them in a single document and this is what namespaces are for. This is the vision behind XML. It's very sad that few people grok it; most prefer to badmouth things they don't understand. A proper markup language should either be low-level and describe, for example, physical layout and such, or should be extensible so I can describe the document in my own terms! I do not write a bunch of divs and h1s, I write, for example, docs for a function with <synopsis>, <parameters>, <examples>, maybe <notes> and so on. And then I mechanically convert it into a low-level language for rendering. HTML is neither: it's not low-level, it's very hard to control even the visual appearance, and it's not extensible either. It's bad in all aspects. (Also, XML not only describes marked-up text, it's the only practical way to work with such text. All modern publishing uses XML.)

Where are you seeing this? Is this not what you're referring to https://svgwg.org/svg2-draft/linking.html#AElementHrefAttribute https://svgwg.org/svg2-draft/linking.html#AElementHrefAttrib... ?

rspeer 10y ago

They're deprecating "a xlink:href" and adding "a href". Sounds good to me. I never had any idea why it had to be "a xlink:href" except that this was designed when someone thought XML namespaces were a good idea.

Mikhail_Edoshin 10y ago
XML namespaces still are a good idea.
- rspeer 10y ago
  What problem do they solve? (Problems that were created by XML in the first place don't count.)
  - Mikhail_Edoshin 10y ago
    With XML namespaces independent development teams can freely design their own structures and interfaces and then mix them in a very granular manner without danger of name clash. This promotes design and reuse of specialized mini-language with exact precise semantic. xlink:href is better than plain href because plain href is an informal convention, while xlink:href is code reuse.
    - rspeer 10y ago
      You're spinning an XML fantasy. XML is not good at describing structures or interfaces. It does not have precise semantics. The semantics of XML are so vague that you can't even tell whether whitespace is significant when parsing it. XML describes marked-up text. And yet it's awkward enough that it's not even used anymore for the most common case of marked-up text (HTML), which is why SVG is evolving to be more like HTML now.
      - ygra 10y ago
        SVG is evolving to be more like HTML because browsers suck at embedded XML content in HTML tag soup.
      - Mikhail_Edoshin 10y ago
        The semantic of a computer language (and a markup language in particular) is what the code does with it. Sometimes the code uses whitespace and sometimes it doesn't; XML doesn't enforce either way and leaves this up to the app. When necessary you can explicitly mark your preference in different parts of the tree with the 'xml:space' attribute. This attribute has precise and unambiguous semantic. It is also another example of why namespaces are important: it's a universal attribute that can be used with any XML document, by the virtue of namespaces it will never conflict with anything, it has a clear and small area of responsibility so any software vendor can easily implement it, you don't need to invent your own conventions or whatever, just reuse it. By comparison, HTML has almost no semantic. You have no idea what the code (which code, by the way?) is going to do with your 'article' tags or tell exactly how 'nav' is different from 'menu'; this spins endless debate about which tag to use. I remember how people argued that using 'dl' for figures with captions was, you know, "semantic markup" :) This is not semantic markup. Semantic markup would be things like <date:timestamp value="..." /> that a browser would render in my timezone or <chess:position move="white">...</chess:position> to describe a position on a chessboard so that a search engine could find similar positions or chess parties where this position has occurred. This is semantic markup and this could be semantic Web. And to make this happen we need to be able to develop small and clearly specified mini-languages with precise semantic (=computer instructions) and then mix them in a single document and this is what namespaces are for. This is the vision behind XML. It's very sad that few people grok it; most prefer to badmouth things they don't understand. A proper markup language should either be low-level and describe, for example, physical layout and such, or should be extensible so I can describe the document in my own terms! I do not write a bunch of divs and h1s, I write, for example, docs for a function with <synopsis>, <parameters>, <examples>, maybe <notes> and so on. And then I mechanically convert it into a low-level language for rendering. HTML is neither: it's not low-level, it's very hard to control even the visual appearance, and it's not extensible either. It's bad in all aspects. (Also, XML not only describes marked-up text, it's the only practical way to work with such text. All modern publishing uses XML.)