Namespaces

[Dave Cramer]

I've seen some talk about using new namespaces to accomplish various goals. I'd like to avoid that if possible—it feels like the slippery slope that leads back to EPUB3.

My vision is of content that is as purely HTML5 as possible, but with some conventions (like index.html) that allow us to create books rather than web sites. If we find we need new attributes, I'd prefer something like data-e0-type rather than epub:type, for example.

Dave

[Kjartan Müller]

Avoiding namespacing is a good idea, but I don't think we should use 'data-' attributes for semantic purposes since this is not what they are meant for. Why not use microdata when we need to extend the semantics? 

Kjartan

[Hadrien Gardeur]

data- attributes are for microdata/interactions the equivalent of div for web design: overused.

[Daniel Glazman]

On 27/02/13 16:01, Hadrien Gardeur wrote:

> data- attributes are for microdata/interactions the equivalent of div
> for web design: overused.

I personnally think they're drastically UNDERused. As says the
specification:

« Custom data attributes are intended to store custom data private to
the page or application, for which there are no more appropriate
attributes or elements. «

It's like rel/rev attributes. In the beginning, it was considered as an
abomination to use the provisions of the spec to extend them; then we
realized It Was Good.

</Daniel>

[Hadrien Gardeur]

I guess it depends which tools/framework community you're talking about. It's used all over the place in the Rails community for example.

Also, "custom data private to the page or application" is widely different from something that would be commonly used in a publication format.

[Baldur Bjarnason]

If what we're aiming for is compatibility with both HTML5 and XHTML5 then it's not just a question of avoiding namespaces, they must be ruled out completely and limited only to the namespace declarations that HTML5 allows (SVG, MathML, and Xlink, IIRC). HTML and XHTML aren't nearly as interoperable as people seem to think (e.g. http://wiki.whatwg.org/wiki/HTML_vs._XHTML) and adding any XML-specific features to the format compromises a lot of Daniel's requirements from https://groups.google.com/d/msg/epub-ng/mMegv_DMgho/HmmG2JEz9igJ (which are reqs I happen to agree with, personally).

The problem with using data- attributes is that they are supposed to be used for private application state and storage, they aren't intended to be used for data interoperability or transfer. That's what they invented both microdata and RDA lite for. (I'd prefer RDA lite myself because, unlike microdata, it doesn't overload the id with meaning, but they are functionally identical so which one we go for doesn't matter.)

Or, the simplest solution is to just use the vendor-prefix style that they went with for ARIA in HTML5. That is, epub-type instead of epub:type. This approach has the benefit of working, out of the box, in all major web browsers, in both HTML5 and XHTML. The [epub:type] attribute selector, for example, doesn't work in most IEs (and IIR a few other browsers but I don't have the references at hand so I may be misremembering), so using namespaced attributes with colons breaks the HTML serialisation.

All, IMHO, of course. :-)

- best
- baldur

[Hadrien Gardeur]

Good suggestion Baldur, I'm in favor of adopting vendor-prefix too.

So far we've talked about a single element (epub-type), let's hope we won't need to many of them (I doubt that we'll also import switch, case or trigger).

We talk a lot about the things from EPUB3 that we don't want in EPUB NG, one thing that we have in EPUB3 and that I'd really like to keep would be the structural semantics vocabulary: http://idpf.org/epub/vocab/structure

Aside from indicating the nature of a <nav> element (reading order or TOC), we still need the ability to provide finer grain semantics than what HTML5 provides (at least for something like footnotes).

[Dave Cramer]

On Mar 1, 11:08 am, Hadrien Gardeur <hadrien.gard...@feedbooks.com>
wrote:

> Good suggestion Baldur, I'm in favor of adopting vendor-prefix too.

Forgive my ignorance, but won't that give us validation problems?

>
> We talk a lot about the things from EPUB3 that we don't want in EPUB NG,
> one thing that we have in EPUB3 and that I'd really like to keep would be
> the structural semantics vocabulary:http://idpf.org/epub/vocab/structure

Indeed!

>
> Aside from indicating the nature of a <nav> element (reading order or TOC),
> we still need the ability to provide finer grain semantics than what HTML5
> provides (at least for something like footnotes).

Do you think that we need more than some implementation of the
epub:type vocabulary (with at least the edition of a value like
'spine' to indicate a nav describes the reading order?

Dave

[Hadrien Gardeur]

Do you think that we need more than some implementation of the
epub:type vocabulary (with at least the edition of a value like
'spine' to indicate a nav describes the reading order?

You mean other controlled vocabularies ?

Having some well-identified types at a publication level (through dc:type) would help too. At least for samples, dictionaries and comics.

For the content itself, an epub:type equivalent with the addition of "spine" or "reading-order" seems good enough.