I should say that these figures are weighted by the number of page
loads, so if sniffing for a particular tag is needed for the digg.com
home page, it will show up as a large number. If you don't weight by
traffic, you get similar results, but with slightly different numbers.
Adam
On Sun, Jan
Martin Atkins wrote:
...
If it is true that RDFa can work today with no ill-effect in downlevel
user-agents, what's currently blocking its implementation? Concern for
validation?
It seems to me that many HTML extensions are implemented first and
specified later[1], so perhaps it would be in
Benjamin Hawkes-Lewis wrote:
On 11/1/09 16:52, Calogero Alex Baldacchino wrote:
Well, that's a chance, of course, but that's *not* RDFa as specified by
W3C; for instance, @property is specified as accepting _only_ CURIEs
Good point; I hadn't spotted that.
It's the same with every possible
James Graham wrote:
It should, perhaps set alarm bells ringing that almost every time data-*
attributes come up, people suggest using them to publish data to the web
at large rather than as internal scripting hooks. Since the restrictions
on data-* are not machine checkable, even the majority
Ian Hickson i...@hixie.ch wrote (on 25 July 2008):
I've made [getElementsByClassName] consistent with how classes work in CSS
(case-insensitive for quirks and case-sensitive otherwise).
I was looking for some tests for this API and found some from Opera (found
at
Martin Atkins wrote:
* Some sites are already publishing XFN and/or hCard so consuming
software would need to continue to support these in addition to
FOAF-in-HTML-somehow, which is more work than supporting only XFN and
hCard.
Mitigating this though is GRDDL which allows the hCard+XFN to
Adam Barth wrote:
Extensions are bad news for content sniffing because they can often be
chosen by the attacker. For example, suppose user-uploaded content is
can be downloaded at:
http://example.com/download.php
In most PHP configurations, the attacker can choose whatever file
extension he
On Mon, Jan 12, 2009 at 7:54 AM, Boris Zbarsky bzbar...@mit.edu wrote:
I'm not quite sure what to make of this, actually. Specifically, where is
the 22.19% number for HTML Tags coming from? 22.19% of what? The magic
numbers stuff actually adds up to 100%, but of what?
Sorry, the % was
On Jan 11, 2009, at 14:01, Toby A Inkster wrote:
RDFa *does not* rely on XML namespaces. RDFa relies on eight
attributes: about, rel, rev, property, datatype, content, resource
and typeof. It also relies on a CURIE prefix binding mechanism. In
XHTML and SVG, RDFa happens to use XML
On Jan 11, 2009, at 18:52, Calogero Alex Baldacchino wrote:
However, actually it's the same for RDFa attributes, because they're
not in the spec. From this point of view, introducing six new
attributes, or resorting to an older one is not very different, thus
(again) why RDFa and not eRDF?
code is listed in the formatting category of elements, but isn't dealt with
in the same way as other formatting elements when in the in body insertion
mode. Currently it will fall through to the any other start tag case, so the
note in that case that says This element will be a phrasing element
Benjamin Hawkes-Lewis ha scritto:
After all, support for unknown attributes/elements has never been a
standard de jure, but more of a quirk
Depends what you mean by support I guess.
I just mean that, as far as I know, there is no official standard
requiring UAs to support (parse and
On 2009-01-12 23:15, Toby A Inkster wrote:
Henri Sivonen wrote:
eRDF is very different in not relying on attributes whose qname
contains the substring xmlns.
eRDF is very different in that it is incredibly annoying to use in real
world scenarios (i.e. not hypothetical Hello World examples).
13 matches
Mail list logo
