It turns out it is not easy so early in HTML 5 history, but after looking
http://www.google.com.tw/search?q=validate+HTML5ie=utf-8oe=utf-8
I finally found
http://www.w3.org/QA/2008/08/html5-validator-beta
an HTML 5 validator
http://qa-dev.w3.org/wmvs/HEAD/
and proceeded to find genuine invalid
Aryeh Gregor simetrical+wikil...@gmail.com wrote:
I support using html 5 new features, but I don't like the idea of
starting to strip tags just because we can.
Currently MediaWiki does quite a good work on it. I don't see a reason
to start removing tags. Yes, allegdely there's an space
On Mon, Jul 13, 2009 at 10:40 AM, jida...@jidanni.org wrote:
It turns out it is not easy so early in HTML 5 history, but after looking
http://www.google.com.tw/search?q=validate+HTML5ie=utf-8oe=utf-8
I finally found
http://www.w3.org/QA/2008/08/html5-validator-beta
an HTML 5 validator
On Mon, Jul 13, 2009 at 2:52 PM, Tim Landscheidtt...@tim-landscheidt.de wrote:
I don't know what Platonides' point was specifically but
personally I find hanging tags (e. g. lacking close tags)
very error-prone. I think if one has to explicitly close
elements the probability of a missed one
Aryeh Gregor wrote:
On Fri, Jul 10, 2009 at 8:04 PM, Platonidesplatoni...@gmail.com wrote:
I support using html 5 new features, but I don't like the idea of
starting to strip tags just because we can.
Currently MediaWiki does quite a good work on it. I don't see a reason
to start removing
On Mon, Jul 13, 2009 at 4:42 PM, Platonidesplatoni...@gmail.com wrote:
Aryeh Gregor wrote:
SDCH is not going to be usable anytime in the foreseeable future, AFAICT.
AFAIK it's implemented on Chrome and IE with Gears extension.
Thus not usable for the overwhelming majority of our viewers, and
On Sun, Jul 12, 2009 at 2:43 PM, William Allen
Simpsonwilliam.allen.simp...@gmail.com wrote:
OK, I've looked. I'm certainly no expert in hand editing html, although
I've done more than enough over the years, but I just don't see the
problem that's being solved.
Many/most pages already serve
I've discovered that changing the doctype does actually cause some
slight rendering differences. I don't think this will be a big delay,
but I've disabled HTML 5 doctypes by default (in r53137) until I can
figure out the issue and resolve it.
___
On Sun, Jul 12, 2009 at 1:58 PM, Aryeh
Gregorsimetrical+wikil...@gmail.com wrote:
I've discovered that changing the doctype does actually cause some
slight rendering differences. I don't think this will be a big delay,
but I've disabled HTML 5 doctypes by default (in r53137) until I can
On Sun, Jul 12, 2009 at 2:41 PM, David Gerarddger...@gmail.com wrote:
You should probably write this up for whatwg - practical gotchas in
moving a large site to HTML5.
It was already public knowledge, just that knowledge didn't extend to
me. :) It was only triggered in any event by what
2009/7/12 Aryeh Gregor simetrical+wikil...@gmail.com:
On Sun, Jul 12, 2009 at 2:41 PM, David Gerarddger...@gmail.com wrote:
You should probably write this up for whatwg - practical gotchas in
moving a large site to HTML5.
It was already public knowledge, just that knowledge didn't extend to
On Fri, Jul 10, 2009 at 10:26 AM, David Gerarddger...@gmail.com wrote:
*waves*
I'll forward your post to wikien-l too.
Give us a list of what to do.
Here:
http://en.wikipedia.org/wiki/Talk:Main_Page#Requested_adjustments_to_Main_Page_HTML
It mainly needs testing across various browsers. I
On Fri, Jul 10, 2009 at 8:04 PM, Platonidesplatoni...@gmail.com wrote:
I support using html 5 new features, but I don't like the idea of
starting to strip tags just because we can.
Currently MediaWiki does quite a good work on it. I don't see a reason
to start removing tags. Yes, allegdely
Apparently something ate my last post here. (I think it was my
Chromium nightly build.) Okay, reposting from memory:
After discussion with Brion on IRC, I've provisionally enabled an HTML
5 doctype in r53034:
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/53034
My thoughts on what we
2009/7/10 Aryeh Gregor simetrical+wikil...@gmail.com:
1b) Rope some enwiki sysops into getting rid of all cellpadding,
cellspacing, align, and clear attributes on the Main Page (converting
them to CSS).
*waves*
I'll forward your post to wikien-l too.
Give us a list of what to do.
4)
I support using html 5 new features, but I don't like the idea of
starting to strip tags just because we can.
Currently MediaWiki does quite a good work on it. I don't see a reason
to start removing tags. Yes, allegdely there's an space improvement but
still... Perhaps we should also look into
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Jul 8, 2009 at 3:46 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
There is only a short period of time remaining where a singular
browser recommendation can be done fairly and neutrally. Chrome and
Opera will ship production versions and then there will be options.
Choices are bad for
On Wed, Jul 8, 2009 at 4:43 PM, Marco
Schusterma...@harddisk.is-a-geek.org wrote:
We should not recommend Chrome - as good as it is, but it has serious
privacy problems.
Out of curiosity, why do we need to recommend a browser at all, and
why do we think anyone will listen to our recommendation?
On Wed, 2009-07-08 at 00:59 +0100, David Gerard wrote:
2009/7/7 Brion Vibber br...@wikimedia.org:
We don't want to annoy users, but subtle nudges to a better experience
can be good. :)
(It'd be good to avoid the This site best viewed in Netscape Gold sort
of browser fanboy wars of the
Aryeh Gregor wrote:
On Tue, Jul 7, 2009 at 4:46 PM, Brion Vibberbr...@wikimedia.org wrote:
Technically HTML 4 is pretty much the same in this regard; it's 100%
legitimate SGML and HTML 4 to skip implied opening and closing elements,
drop quotes on attribute values that are unambiguous, etc.
I'm only considering the projects I was going to work on and can't talk for
all the things MediaWiki team should have in mind - I was going to add
support for RDFa (http://www.w3.org/TR/rdfa-syntax/) which currently is W3C
Recomendation, but only for XHTML and even though HTML profiles (or
We need to inform people that the quality of experience can be
substantially improved if they use a browser that supports free formats.
Wikimedia only distributes content in free formats because if you have
to pay for a licensee to view, edit or publish ~free content~ then the
content is not
On Wed, Jul 08, 2009 at 10:58:43AM -0400, William Allen Simpson wrote:
My thought is that the 5 tags that are marked as well-supported could be
used, but be very cautious about abandoning 4. There are a lot of old
machines out there, and many cannot upgrade to newer browsers, because
they
On Wed, Jul 8, 2009 at 2:23 PM, Michael Dalemd...@wikimedia.org wrote:
The current language is For best video playback experience we recommend
_Firefox 3.5_ ... but I am open to adjustments.
I'd drop the word experience. It's superfluous marketing speak.
So the notice chain I'm planning on
2009/7/8 Michael Dale md...@wikimedia.org:
We have requested that Apple and IE support free formats but they have
chosen not to. Therefore we are in a position where we have to recommend
a browser that does have a high quality user experience in supporting
the formats. We are still making
David Gerard wrote:
A method that doesn't say your browser sucks but shows it:
You are using Safari without XiphQT. Install the Ogg codecs _here_
for a greatly improved Wikimedia experience.
You are using Internet Explorer. Install the Ogg codecs _here_ for a
greatly improved Wikimedia
2009/7/8 j...@v2v.cc:
David Gerard wrote:
You are using Internet Explorer. Install the Ogg codecs _here_ for a
greatly improved Wikimedia experience.
Internet Explorer does not support the video tag, installing Ogg
DirectShow filters does not help there.
Yes, I realised this just after
You use quicktime + Xiph quicktime components (ie the codec)
-Mike
On Wed, 2009-07-08 at 20:06 +0100, David Gerard wrote:
2009/7/8 j...@v2v.cc:
David Gerard wrote:
You are using Internet Explorer. Install the Ogg codecs _here_ for a
greatly improved Wikimedia experience.
Internet
2009/7/8 Gregory Maxwell gmaxw...@gmail.com:
Since, at the moment, firefox is the only non-beta browser with direct
support I don't see why plugging Firefox would be controversial. It's
a matter of fact that it works best with Firefox 3.5 or Safari+XiphQT.
Later when there are several options
On Wed, Jul 8, 2009 at 3:06 PM, David Gerarddger...@gmail.com wrote:
2009/7/8 j...@v2v.cc:
David Gerard wrote:
You are using Internet Explorer. Install the Ogg codecs _here_ for a
greatly improved Wikimedia experience.
Internet Explorer does not support the video tag, installing Ogg
On Wed, Jul 8, 2009 at 10:58 AM, William Allen
Simpsonwilliam.allen.simp...@gmail.com wrote:
Remember Postel's robustness principle (paraphrased):
be conservative in what you send, liberal in what you accept
This applies only if there's some reason to be conservative. There's
no reason to
On Wed, Jul 8, 2009 at 11:15 AM, Sergey
Chernyshevsergey.chernys...@gmail.com wrote:
I'm only considering the projects I was going to work on and can't talk
for
all the things MediaWiki team should have in mind - I was going to add
support for RDFa (http://www.w3.org/TR/rdfa-syntax/)
On Wed, Jul 8, 2009 at 5:41 PM, Sergey
Chernyshevsergey.chernys...@gmail.com wrote:
I see your point - video is clearly more popular then RDFa and if you're
willing to go off-standard to support it, it's might be a reasonable
decision for a site like Wikipedia. Not sure what is the rush for
On Tue, Jul 7, 2009 at 1:54 AM, Aryeh
Gregorsimetrical+wikil...@gmail.com wrote:
[snip]
* We could support video/audio on conformant user agents without
the use of JavaScript. There's no reason we should need JS for
Firefox 3.5, Chrome 3, etc.
Of course, that could be done without switching
Okay, first thoughts:
On Mon, Jul 6, 2009 at 11:54 PM, Aryeh Gregor
simetrical+wikil...@gmail.comsimetrical%2bwikil...@gmail.com
wrote:
It's clear at this point that HTML 5 will be the next version of HTML.
It was obvious for a long time that XHTML was going nowhere, but now
it's official:
On 07/07/2009, at 7:37 AM, Remember the dot wrote:
Okay, first thoughts:
On Mon, Jul 6, 2009 at 11:54 PM, Aryeh Gregor
simetrical+wikil...@gmail.comsimetrical%2bwikil...@gmail.com
wrote:
It's clear at this point that HTML 5 will be the next version of
HTML.
It was obvious for a long
On Tue, Jul 7, 2009 at 2:37 AM, Remember the
dotrememberthe...@gmail.com wrote:
That page clearly says that there will be an XHTML 5. XHTML is not going
away.
By XHTML I meant the family of standards including XHTML 1.0, 1.1,
2.0, etc.. XHTML 5 is identical to HTML 5 except with a different
Great, looks like HTML5 vs. XHTML fight is infecting everything.
Just my 2 cents - I don't think that switching to new not yet W3C
Recomendation is a good idea - many extensions and features are not yet
finished (e.g. RDFa support for it) and considering a huge commotion in this
area it might not
On Tue, Jul 7, 2009 at 2:29 PM, Sergey
Chernyshevsergey.chernys...@gmail.com wrote:
Just my 2 cents - I don't think that switching to new not yet W3C
Recomendation is a good idea - many extensions and features are not yet
finished (e.g. RDFa support for it)
Much of the spec is very stable. We
On Tue, Jul 7, 2009 at 2:46 PM, Aryeh
Gregorsimetrical+wikil...@gmail.com wrote:
Much of the spec is very stable. We would not be using any part
that's likely to change -- in most cases, only parts that have
multiple interoperable implementations. Such parts of the spec will
not change
Aryeh Gregor wrote:
On Tue, Jul 7, 2009 at 2:37 AM, Remember the
dotrememberthe...@gmail.com wrote:
Why be cruel to our bot operators? XHTML is simpler and more consistent than
tag soup HTML, and it's a lot easier to find a good XML parser than a good
HTML parser.
Because it will make the
I think if the playback system is java in ~any browser~ we should
~softly~ inform people to get a browser with native support if they
want a high quality video playback experience.
The cortado applet is awesome ... but startup time of the java vm is
painful compared to other user experiences
At a minimum, I'm glad to see the dead-ended XHTML 2 working group
officially killed; actual compatible implementations of ongoing work are
happening in the HTML 5 world and that's where the future definitely is.
I don't see much need for us to stick with the XML formulation for the
next
Michael Dale wrote:
I think if the playback system is java in ~any browser~ we should
~softly~ inform people to get a browser with native support if they
want a high quality video playback experience.
The cortado applet is awesome ... but startup time of the java vm is
painful compared
Also should be noted a simple patch for oggHandler to output video and
use the mv_embed library is in the works see:
https://bugzilla.wikimedia.org/show_bug.cgi?id=18869
you can see it in action a few places like
http://metavid.org/wiki/File:FolgersCoffe_512kb.1496.ogv
Also note my ~soft~ push
2009/7/7 Brion Vibber br...@wikimedia.org:
Michael Dale wrote:
I think if the playback system is java in ~any browser~ we should
~softly~ inform people to get a browser with native support if they
want a high quality video playback experience.
The cortado applet is awesome ... but startup
On Tue, Jul 7, 2009 at 7:53 PM, Michael Dalemd...@wikimedia.org wrote:
[snip]
I don't really have apple machine handy to test quality of user
experience in OSX safari with xiph-qt. But if that is on-par with
Firefox native support we should probably link to the component install
instructions
48 matches
Mail list logo
