3 ms·

Once I've joined a project and there was a problem with text selection in embedded PDF.js It took some time to find out that CSS rules clashed with PDF.js invi

Once I've joined a project and there was a problem with text selection in embedded PDF.js It took some time to find out that CSS rules clashed with PDF.js invisible markup that provides text for selection on top of <canvas> rendered document. And I am not the only one [1]. Solution? Embed namespace in class name [2] like it is C - gtk_window_new, glBegin, XOpenDisplay. Yes, namespaces in XPath looks awful, entire plain text XML authoring is awful. XML is application format (hint application/xml), maybe it should not be touched without XML editor. [1] https://www.google.com/search?q=css+name+collision https://www.google.com/search?q=css+name+collision [2] http://getbem.com/introduction/ http://getbem.com/introduction/

lmm 6y ago
> It took some time to find out that CSS rules clashed with PDF.js invisible markup that provides text for selection on top of <canvas> rendered document. > And I am not the only one [1]. Solution? Embed namespace in class name [2] like it is C - gtk_window_new, glBegin, XOpenDisplay. OK, that's a good example. Though I'd argue that in structured data like XML it's much less likely to happen - you wouldn't generally use an xpath that was just "all tags of the given name", whereas applying styling to all cases of a given CSS class anywhere in the document is relatively common. In any case, the cure is far worse than the disease. > Yes, namespaces in XPath looks awful, entire plain text XML authoring is awful. XML is application format (hint application/xml), maybe it should not be touched without XML editor. But in that case why bother with a textual format with all the downsides thereof? Something like Thrift or Protocol Buffers makes for much better application formats.
- sergeykish 6y ago
  I don't know. XML looks like a hype pushed too far. Like server side javascript, nosql, docker, kubernetes but with a strong support from the industry. It is really hard to gather useful parts. Entire XHTML push for the sake of it was misleading. Semantic web. Like publish data and they will come. This does not work, data should be crafted with specific consumption in mind. XSLT as XML makes sense when it is transformed with XSLT. Even than authoring is better with human readable form like RELAX NG compact syntax. What is meta and what is content defined on consumption point. XML inherited totally needless attributes that just brings confusion. Namespaces looks like a least of sins. They are useful. So what is a life in Xmlendom looks like? Documents with slight overhead for human consumption (in browser), just a few clicks to extract relevant data, a few more clicks to make parser, a few clicks to make transformation. XML plain text editing is as pointless as DOCX plain text editing.
  - lmm 6y ago
    > Namespaces looks like a least of sins. They are useful. Well, the most immediate concrete practical problems I have when working with XML are a) in the default configuration, a lot of parsers will throw an error if they can't load the DTD over the network, which is an accident waiting to happen b) XPaths written in the most obvious way will silently fail to match anything until you've done a bunch of extra configuration to get the namespaces set up right. Maybe they're not the deepest problems, but the surface experience matters too. > So what is a life in Xmlendom looks like? Documents with slight overhead for human consumption (in browser), just a few clicks to extract relevant data, a few more clicks to make parser, a few clicks to make transformation. In my experience anyone who can actually understand those transformations well enough to maintain them would rather be using a real programming language instead of clicking. > XML plain text editing is as pointless as DOCX plain text editing. So why not something like protobuf that's easier to work with then?
    - sergeykish 6y ago
      I am a wrong person to ask. I've never advertised XML as machine to machine format. I've used SOAP, XML configs, it was not smooth. My interaction with XML mostly was in browser where it shines compared to HTML as application format. I have my own list in defense of XML, wrote first one [1]. Unfortunately your argument is "I don't need it" which is not a lot. Imagine Unicode instead of XML "ASCII works for me, Unicode does not fit in char, not even in wchar, surrogate pairs, access by index, wrong encoding". I mean, sure, stick to ASCII. Now, transformations, the idea was people would catch clicking quicker than real programming language. Turtle, Scratch have its place. Visual Basic has its place. Excel has quite big place. [1] http://sergeykish.com/pre-newline-preserved-in-xhtml-test http://sergeykish.com/pre-newline-preserved-in-xhtml-test
      - lmm 6y ago
        > My interaction with XML mostly was in browser where it shines compared to HTML as application format. I have my own list in defense of XML, wrote first one [1]. If that's your best argument for XML then I'm thoroughly unconvinced. I can see the theoretical argument for the XML behaviour, but the HTML behaviour seems a lot more useful in practice - a lot of the point of using pre is to preserve vertical alignment, and with the XML approach the first line is forced to be misaligned in the source. > Unfortunately your argument is "I don't need it" which is not a lot. Imagine Unicode instead of XML "ASCII works for me, Unicode does not fit in char, not even in wchar, surrogate pairs, access by index, wrong encoding". I mean, sure, stick to ASCII. But there's a compelling argument for using unicode: a lot of characters can't be represented in ASCII, and traditional codepages don't let you use characters from multiple languages at the same time. Where's the corresponding argument for XML? > Now, transformations, the idea was people would catch clicking quicker than real programming language. Turtle, Scratch have its place. Visual Basic has its place. Excel has quite big place. But not everything has a place. Some tools are just bad, and point-and-click builders are one such thing IME.

lmm 6y ago

> It took some time to find out that CSS rules clashed with PDF.js invisible markup that provides text for selection on top of <canvas> rendered document. > And I am not the only one [1]. Solution? Embed namespace in class name [2] like it is C - gtk_window_new, glBegin, XOpenDisplay. OK, that's a good example. Though I'd argue that in structured data like XML it's much less likely to happen - you wouldn't generally use an xpath that was just "all tags of the given name", whereas applying styling to all cases of a given CSS class anywhere in the document is relatively common. In any case, the cure is far worse than the disease. > Yes, namespaces in XPath looks awful, entire plain text XML authoring is awful. XML is application format (hint application/xml), maybe it should not be touched without XML editor. But in that case why bother with a textual format with all the downsides thereof? Something like Thrift or Protocol Buffers makes for much better application formats.

sergeykish 6y ago
I don't know. XML looks like a hype pushed too far. Like server side javascript, nosql, docker, kubernetes but with a strong support from the industry. It is really hard to gather useful parts. Entire XHTML push for the sake of it was misleading. Semantic web. Like publish data and they will come. This does not work, data should be crafted with specific consumption in mind. XSLT as XML makes sense when it is transformed with XSLT. Even than authoring is better with human readable form like RELAX NG compact syntax. What is meta and what is content defined on consumption point. XML inherited totally needless attributes that just brings confusion. Namespaces looks like a least of sins. They are useful. So what is a life in Xmlendom looks like? Documents with slight overhead for human consumption (in browser), just a few clicks to extract relevant data, a few more clicks to make parser, a few clicks to make transformation. XML plain text editing is as pointless as DOCX plain text editing.
- lmm 6y ago
  > Namespaces looks like a least of sins. They are useful. Well, the most immediate concrete practical problems I have when working with XML are a) in the default configuration, a lot of parsers will throw an error if they can't load the DTD over the network, which is an accident waiting to happen b) XPaths written in the most obvious way will silently fail to match anything until you've done a bunch of extra configuration to get the namespaces set up right. Maybe they're not the deepest problems, but the surface experience matters too. > So what is a life in Xmlendom looks like? Documents with slight overhead for human consumption (in browser), just a few clicks to extract relevant data, a few more clicks to make parser, a few clicks to make transformation. In my experience anyone who can actually understand those transformations well enough to maintain them would rather be using a real programming language instead of clicking. > XML plain text editing is as pointless as DOCX plain text editing. So why not something like protobuf that's easier to work with then?
  - sergeykish 6y ago
    I am a wrong person to ask. I've never advertised XML as machine to machine format. I've used SOAP, XML configs, it was not smooth. My interaction with XML mostly was in browser where it shines compared to HTML as application format. I have my own list in defense of XML, wrote first one [1]. Unfortunately your argument is "I don't need it" which is not a lot. Imagine Unicode instead of XML "ASCII works for me, Unicode does not fit in char, not even in wchar, surrogate pairs, access by index, wrong encoding". I mean, sure, stick to ASCII. Now, transformations, the idea was people would catch clicking quicker than real programming language. Turtle, Scratch have its place. Visual Basic has its place. Excel has quite big place. [1] http://sergeykish.com/pre-newline-preserved-in-xhtml-test http://sergeykish.com/pre-newline-preserved-in-xhtml-test
    - lmm 6y ago
      > My interaction with XML mostly was in browser where it shines compared to HTML as application format. I have my own list in defense of XML, wrote first one [1]. If that's your best argument for XML then I'm thoroughly unconvinced. I can see the theoretical argument for the XML behaviour, but the HTML behaviour seems a lot more useful in practice - a lot of the point of using pre is to preserve vertical alignment, and with the XML approach the first line is forced to be misaligned in the source. > Unfortunately your argument is "I don't need it" which is not a lot. Imagine Unicode instead of XML "ASCII works for me, Unicode does not fit in char, not even in wchar, surrogate pairs, access by index, wrong encoding". I mean, sure, stick to ASCII. But there's a compelling argument for using unicode: a lot of characters can't be represented in ASCII, and traditional codepages don't let you use characters from multiple languages at the same time. Where's the corresponding argument for XML? > Now, transformations, the idea was people would catch clicking quicker than real programming language. Turtle, Scratch have its place. Visual Basic has its place. Excel has quite big place. But not everything has a place. Some tools are just bad, and point-and-click builders are one such thing IME.