Re: [whatwg] HTML tags for POEM and MUSIC LYRICS
On 11.12.2017 11:39, Christoph Päper wrote: > As with and , HTML could also add or something similar to > embed MusicXML. Lyrics are a subset of musical notation and poems are, > arguably, a special kind of lyrics (or the other way around). This would require change to HTML parsing rules which ideally shoudn't ever happen again. Easier approach is to use XHTML syntax and simply embedded fragment of specific XML vocabulary. It's pity that extensibility has been largely thrown away when HTML5 was designed. BTW, MusicXML is really not appropriate for poems. There is existing markup for poems in TEI: http://teibyexample.org/modules/TBED04v00.htm Jirka -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML and Web consulting and training services DocBook/DITA customization, custom XSLT/XSL-FO document processing -- Bringing you XML Prague conferencehttp://xmlprague.cz --
Re: [whatwg] Obsolete Feature [hgroup]
On 18.2.2015 0:15, Barry Smith wrote: I have read where the W3C has made the hgroup element obsolete, http://www.w3.org/html/wg/drafts/html/master/obsolete.html#non-conforming-features . I see the specification is still in the WHATWG HTML: The Living Standard specifications. Are there any plans to remove this element from the specification? If not, as a web developer, I try extremely hard to follow protocol and create a valid and semantically correct document. How should I handle this? W3C version of HTML5 is more conservative with some controversial features so from the perspective of authoring web pages I would suggest following what W3C spec says, not WHATWG Living Standard. Jirka -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML and Web consulting and training services DocBook/DITA customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep. -- Bringing you XML Prague conferencehttp://xmlprague.cz --
Re: [whatwg] The src-N proposal
On 19.11.2013 23:22, Tab Atkins Jr. wrote: +1. I'm totally fine with this, if the people who disliked multiple attrs are okay with multiple elements. +1 -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep. -- Bringing you XML Prague conferencehttp://xmlprague.cz --
Re: [whatwg] The src-N proposal
On 18.11.2013 14:38, Marcos Caceres wrote: we really need to, srcset. The developer community already made significant sacrifices in compromising on picture because of issues that implementers raised about nested elements Are those issues with nested elements described somewhere? I wasn't able to find anything and I would really like to know what the issue was. of constituencies. Let’s not further erode those principles for the sake of markup aesthetics. It's not just about aesthetics. From markup point of view src-n goes against common sense and principles. Existing APIs and languages for working with markup don't have easy way to access src-n attributes, especially if order based on n is significant. This is very different from nested elements where it's very easy to iterate over them. Try to write JS+DOM, or XPath, or ... your preferred language here ... code for looping through src-n attributes in a right order. Compare it to the same code for subelements, which are ordered and have same name. Jirka -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep. -- Bringing you XML Prague conferencehttp://xmlprague.cz --
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On 13.11.2013 13:48, Silvia Pfeiffer wrote: img class=artdirected src=foo.jpg src-small=foo-small.jpg src-medium=foo-medium.jpg src-big=foo-big.jpg Do you expect that there will be just predefined set of src-* attributes or user can define as many of them as he/she wants and use arbitrary identifier after src-? If the later is one, then validation and content completion in HTML source editors will be nightmare. No different to data-* . Not completely. In practice you don't use completely arbitrary data-* attributes just few of them needed by JS library you use on the page. So you know which JS libraries are imported you can know which data-* attributes could be there. Jirka -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep. -- Bringing you XML Prague conferencehttp://xmlprague.cz --
Re: [whatwg] imgset responsive imgs proposition (Re: The src-N proposal)
On 13.11.2013 2:56, Christian Biesinger wrote:
For a bit more presentation, and while we're inventing new syntax
anyway, how about this:
style
@media (min-width: 480px) {
.artdirected { content: replaced url(attr(src-small)); }
...
/style
...
img class=artdirected src=foo.jpg src-small=foo-small.jpg
src-medium=foo-medium.jpg src-big=foo-big.jpg
Do you expect that there will be just predefined set of src-* attributes
or user can define as many of them as he/she wants and use arbitrary
identifier after src-?
If the later is one, then validation and content completion in HTML
source editors will be nightmare.
Jirka
--
--
Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz
--
Professional XML consulting and training services
DocBook customization, custom XSLT/XSL-FO document processing
--
OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep.
--
Bringing you XML Prague conferencehttp://xmlprague.cz
--
Re: [whatwg] Zip archives as first-class citizens
On 13.9.2013 12:10, Robin Berjon wrote: I would rather we figured this out without link, but apart from the indirection I reckon this approach has some nice properties and might work if more direct ones don't. Also don't forget that while linking is the hardest part of this ZIP circus there is another missing piece -- normative definition of portable and RF subset of ZIP. SC34 started some initial work on such ZIP profile recently: http://www.itscj.ipsj.or.jp/sc34/open/1855.pdf So if some sort of ZIP packaging spec should to appear then it should reference such subset of ZIP not the full definition of ZIP format from PKWare. Jirka -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep. -- Bringing you XML Prague conferencehttp://xmlprague.cz --
Re: [whatwg] Proposal: Change HTML spec to allow any arbitrary value for the meta name attribute
On 4.6.2013 12:33, Robin Berjon wrote: developers reach for. If the validation errors on metadata names served a clearly useful purpose I'd suggest waiting it out until using data-* becomes more of a reflex, but that doesn't seem to be the case so the pain inflicted in the meantime doesn't appear to be useful. I think that spec is not really not good in this aspect and should be changed along the lines Mike proposed. The spec should allow any name and validator optionally could emit warning if unregistered name is used. But it shouldn't be treated as error -- meta was always extension point and it's unrealistic to think that every piece of metadata will go to registry. Jirka div data-gi=could-not-resist If there would be real distributed extensibility on metadata names... /div -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep. -- Bringing you XML Prague conferencehttp://xmlprague.cz --
[whatwg] Microdata status
Hi, are there any plans to change Microdata API? From the following conversation between Chromium developers it's not clear to me whether they consider API itself bad or only their implementation. https://groups.google.com/a/chromium.org/forum/m/#!topic/blink-dev/b54nW_mGSVU Any insight welcomed. Jirka -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep. -- Bringing you XML Prague conferencehttp://xmlprague.cz --
Re: [whatwg] Sortable Tables
On 6.11.2012 23:18, Silvia Pfeiffer wrote: * data-type: date, number, text etc which determines the comparison function used in sort It would be very difficult to support sorting on dates and numbers as in HTML they are usually present formatted using specific locale. So there should be additional attribute added to td/th which can hold sort key which will override cell contents, something like td sortas=2012-11-0711. listopadu 2012/td Jirka -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member --
Re: [whatwg] main element parsing behaviour
On 7.11.2012 12:46, Simon Pieters wrote: I'm not convinced that we should freeze the parser now just because we have reached interop. I think not changing the parser here makes main (and other future elements; whatever we do here sets a precedent for future elements) inconsistent with the rest of HTML. In the long term, having main and aside parse differently just because we didn't want to change the behavior from 2012-era browsers will seem silly. Moreover, it will complicate the already complicated rules about when /p may be omitted (in terms of how people think of the rule), which means that we might have to say that /p is always required. Changing parser each time new element is added is really evil idea and sign of a bad design. Parsing algorithm should be either not touched at all, or it should be promptly changed to treat all unknown elements in other way if the current treatment of unknown elements is not suitable for some reason. Jirka -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member --
Re: [whatwg] main element parsing behaviour
On 7.11.2012 13:13, Simon Pieters wrote: If we were to design a system where we can make up new elements that go in one of those categories without changing the parser, I think we effectively have to put a magic string in the tag name, e.g. any element that starts with block is treated like address, but that has disadvantages: * Looking at a substring of the tag name complicates the parser and probably ruins some optimizations. * It means new non-inline elements will have long, ugly two-word names which is inconsistent with the rest of the language. Indeed, this doesn't seem very appealing. I can imagine other designs as well but they don't seem any better. In conclusion, I think changing the parser when we introduce a new block or void element is a better approach. I think it's better to treat all new elements as inline (from parsing point of view) then to change algorithm each time. Changing parsing each time also means that such changes can't be undone. Look for example at hgroup. It's supported by parsing algorithm as implemented in browsers, so it will remain in spec forever even when it's not actually implemented. With such approach parsing algorithm will became boneyard of proposed but later thrown away elements over the time. Jirka -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member --
Re: [whatwg] main element parsing behaviour
On 7.11.2012 13:42, Simon Pieters wrote: Look for example at hgroup. It's supported by parsing algorithm as implemented in browsers, so it will remain in spec forever even when it's not actually implemented. With such approach parsing algorithm will became boneyard of proposed but later thrown away elements over the time. I think we shouldn't put the parsing algorithm on a pedestal while not giving the same treatment to the default UA style sheet or other requirements related to an element that have to be implemented. The difference is that deficiency of parsing algorithm can't be compensated by JS or CSS. Until new element is widely supported you can define it's styling in your CSS file or link to Javascript shim which will provide functionality in older browsers. But I don't think that you can alter parsing algorithm in the similar way. Web browsers are now upgraded much more frequently and regularly so change to PA might look like non problem. But various non-browser applications are relying on HTML5 parsing libraries and those will not be regularly updated. Jirka -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member --
