[Bug 40329] Don't use hacks to replicate a browser function, either let align="" pass through or not; in HTML5
https://bugzilla.wikimedia.org/show_bug.cgi?id=40329 --- Comment #34 from Krinkle 2012-11-01 18:11:57 UTC --- Feature removed (bug 40632) in Change-Id: I4e86305520a3b22ef88381caab55d24abac932e3. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40329] Don't use hacks to replicate a browser function, either let align="" pass through or not; in HTML5
https://bugzilla.wikimedia.org/show_bug.cgi?id=40329 Andre Klapper changed: What|Removed |Added Depends on||40632 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40329] Don't use hacks to replicate a browser function, either let align="" pass through or not; in HTML5
https://bugzilla.wikimedia.org/show_bug.cgi?id=40329 Bug 40329 depends on bug 40632, which changed state. Bug 40632 Summary: Kill $wgCleanupPresentationalAttributes from MediaWiki core https://bugzilla.wikimedia.org/show_bug.cgi?id=40632 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40329] Don't use hacks to replicate a browser function, either let align="" pass through or not; in HTML5
https://bugzilla.wikimedia.org/show_bug.cgi?id=40329 Krinkle changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED AssignedTo|wikibugs-l@lists.wikimedia. |krinklem...@gmail.com |org | Target Milestone|Future release |1.20.x release --- Comment #35 from Krinkle 2012-11-20 19:11:14 UTC --- Landed in master and merged to 1.20.x. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40329] Don't use hacks to replicate a browser function, either let align="" pass through or not; in HTML5
https://bugzilla.wikimedia.org/show_bug.cgi?id=40329 TMg changed: What|Removed |Added Summary|Block elements inside |Don't use hacks to |elements with align="" |replicate a browser |should use margin:auto; in |function, either let |HTML5 |align="" pass through or ||not; in HTML5 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40329] Don't use hacks to replicate a browser function, either let align="" pass through or not; in HTML5
https://bugzilla.wikimedia.org/show_bug.cgi?id=40329 --- Comment #20 from Jesús Martínez Novo 2012-09-24 16:42:11 UTC --- Just FYI: Bug 40306 is handling the problem with the align properties in HTML5 not being translated correctly to CSS. That bug was fixed and changes were already deployed to Wikimedia servers, so the original problem is no longer occurring. Yes, align properties aren't being outputted now, but browsers should render now the tables correctly as if they were still there. I think that transforming properties to valid HTML5/CSS syntax is fine, when it's done properly and without breaking things. No need to completely drop the align support *now*. The gradually remove support from those elements/attributes is being handled on bug 24529. Is it really necessary to leave this bug open and continue commenting on it? What is it's current purpose? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40329] Don't use hacks to replicate a browser function, either let align="" pass through or not; in HTML5
https://bugzilla.wikimedia.org/show_bug.cgi?id=40329 --- Comment #21 from Daniel Friesen 2012-09-24 17:14:11 UTC --- (In reply to comment #19) > (In reply to comment #18) > > two users on different browsers may see two different things > > What are you talking about? This is not true. In the previous Wikipedia setup > with HTML5 disabled all users got the same HTML output and it looked the same > in all web browsers. Now this is broken. It does *not* look the same when a > template is tested locally for example. The hack creates a *different* result > when the finished code is finally put into a template. The hack *changes* the > *meaning* of the code no matter if these attributes were used for a reason or > not. This is confusing as hell. It makes creating templates a mess (not that > it > isn't a mess anyway). > > None of your examples ever changed the *meaning* of some code, not even the ID > example. You originally said "because you never can say how browsers were handling it (and different browsers handle stuff differently)" which seamed to imply the suggestion of a browser quirk where different browsers have different results for the same deprecated markup. That's what this separate sub-discussion was about. > > You just contradicted yourself. You just said that you were ok with align > > being removed from the whitelist. Yet that breaks things. > > I will try to speak very slow: Either remove all align attributes (drop it > from > the whitelist) or let them pass through (keep it whitelisted). In other words, > either break *everything* or *nothing*. The current hack breaks some *random* > stuff. This is not only confusing, it's completely unnecessary because every > web browser is able to handle the align attributes well. You are replicating > something that clearly is the responsibility of the web browser. Browsers support deprecated and removed html so that they can correctly render ancient websites written using HTML 3.2. We are not outputting HTML 3.2, so it's our responsibility to not output stuff that was removed. As the maintainers of WikiText it is also our responsibility to ensure that pages written in WikiText continue to work except when there is a bug we have to fix and we can't fix that bug without breaking a minimal number of pages. Outputting invalid HTML is a bug. Breaking every article when we are capable of only breaking 5 of every 6. Hence fixing the bug by translating WikiText to use valid HTML that keeps as many articles working as we can is preferable to just breaking everything that relied on the bug. > > While fixing an issue that doesn't look broken when you look at > > it is really hard. > > Again, this must be a joke. That's exactly the problem of the current hack. It > makes broken code *not* look broken. It does not fix anything. It does not > help > people to fix their outdated template code. It does the *opposite*. It's a > stupid counterproductive hack. All it does is adding confusion and breaking > some random templates for no good reason. If the output doesn't look broken to you. The output doesn't rely on browser quirks that would cause it to look broken to another user. And the output is not invalid html that constitutes a bug we need to fix. Then your wiki page is not broken. ie: If you use align="center" in WikiText, and the translation to style="text-align: center;" in HTML looks ok in your articles. Then there is no reason to stop using align="center". You're writing WikiText not HTML, so whether your WikiText validates under the HTML spec is irrelevant. When the output is valid. It's only broken if it looks broken. > > It's still a valid point that translations still work in most situations > > Again, *not* translating this worked in *all* situations till last week. You > can't say all the templates we developed in the past years are broken. They > are > *not*. They were tested in all browsers. Nothing was broken till you started > to > change our code. Yes, they were broken. Our code outputted attributes that were deprecated and removed from html into page output. ie: MediaWiki outputted incorrect markup. Which is a bug in the software. And you made templates dependent on browser quirks and MediaWiki outputting bad markup forever... ie: You relied on a bug in the software. So yes, your templates were broken And now we're fixing the bug, repurposing that WikiText to output valid HTML/CSS that is as close as we possibly can to how you wrote templates intending to behave. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40329] Don't use hacks to replicate a browser function, either let align="" pass through or not; in HTML5
https://bugzilla.wikimedia.org/show_bug.cgi?id=40329 --- Comment #22 from TMg 2012-09-24 17:56:12 UTC --- (In reply to comment #20) > when it's done properly and without breaking things. It is not done properly. It breaks things. This is what this bug is about. See my example in the first comment. (In reply to comment #21) > You originally said "because you never can say how browsers were handling it > (and different browsers handle stuff differently)" I have not said that. > it's our responsibility to not output stuff that was removed. It was not removed. Every web browser in the world is able to render align attributes properly. With your current hack you are doing the job of the we browser and you are doing it bad. There is no need to replicate something that *every* web browser in the world can do by it's own. > it is also our responsibility to ensure that pages written in WikiText > continue to work Then do this please. Currently an unknown number of WikiText pages do not continue to work. > except when there is a bug we have to fix What bug? There was no bug with the align properties. It worked fine for decades and it will continue to work for decades. > Breaking every article What are you talking about? Absolutely nothing will break if you output the align attributes. > It's only broken if it looks broken. Again, what are you talking about? It *does* look broken. This is what this bug is about. > MediaWiki outputted incorrect markup. Then drop your support for this markup if you consider it "incorrect". Tell the people it will be dropped, give them some time and then drop it. Either this or continue to support it. But don't change the *meaning* of *my* code. > So yes, your templates were broken No, they were not. They worked fine and they will work find for the next decades. I tested them in every browser. There was no bug. *You* introduced a bug. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40329] Don't use hacks to replicate a browser function, either let align="" pass through or not; in HTML5
https://bugzilla.wikimedia.org/show_bug.cgi?id=40329 --- Comment #23 from Daniel Friesen 2012-09-24 18:28:41 UTC --- (In reply to comment #22) > (In reply to comment #20) > > when it's done properly and without breaking things. > > It is not done properly. It breaks things. This is what this bug is about. See > my example in the first comment. > > (In reply to comment #21) > > You originally said "because you never can say how browsers were handling it > > (and different browsers handle stuff differently)" > > I have not said that. > > > it's our responsibility to not output stuff that was removed. > > It was not removed. Every web browser in the world is able to render align > attributes properly. With your current hack you are doing the job of the we > browser and you are doing it bad. There is no need to replicate something that > *every* web browser in the world can do by it's own. We output HTML5. Align was removed from HTML5. Browsers support align to support HTML 3.2. We don't output HTML 3.2. Hence what the browser can do is irrelevant, it's our responsibility to not put align in the page output. > > it is also our responsibility to ensure that pages written in WikiText > > continue to work > > Then do this please. Currently an unknown number of WikiText pages do not > continue to work. > > except when there is a bug we have to fix > > What bug? There was no bug with the align properties. It worked fine for > decades and it will continue to work for decades. align is not valid output it's our job not to output it, that is a bug. > > Breaking every article > > What are you talking about? Absolutely nothing will break if you output the > align attributes. That was a reference to the suggestion of removing align="" entirely. If we do that then everything breaks instead of just some things. > > It's only broken if it looks broken. > > Again, what are you talking about? It *does* look broken. This is what this > bug > is about. You said "It makes broken code *not* look broken. It does not fix anything. It does not help people to fix their outdated template code. It does the *opposite*." I replied saying that if the output does not look broken then the code is not broken. In other words, I'm saying that if something uses align="" but does not look broken after we translate that to css. Then the template is not broken and there is no need to change the template code. > > MediaWiki outputted incorrect markup. > > Then drop your support for this markup if you consider it "incorrect". Tell > the > people it will be dropped, give them some time and then drop it. Either this > or > continue to support it. But don't change the *meaning* of *my* code. MediaWiki's HTML output is incorrect. That doesn't make WikiText input incorrect. We are not going to drop something 100% from WikiText just to fix invalid HTML output when we can instead output valid HTML that works 90% of the time. > > So yes, your templates were broken > > No, they were not. They worked fine and they will work find for the next > decades. I tested them in every browser. There was no bug. *You* introduced a > bug. Outputting invalid markup is a bug. It doesn't matter if it worked fine, it was a bug. I would appreciate it if you would stop splitting up my sentences, replying to a chunk of a sentence as if it were a whole senescence, and completely omitting other parts of the same paragraph as if they didn't exist. Frankly it makes it look like you are trying to commit the "Strawman" logical fallacy just to make a point. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40329] Don't use hacks to replicate a browser function, either let align="" pass through or not; in HTML5
https://bugzilla.wikimedia.org/show_bug.cgi?id=40329 --- Comment #24 from TMg 2012-09-27 12:02:52 UTC --- I have no idea who Strawman is. You say the align attributes need to be removed from the HTML output. I don't see why this needs to be done *now*. Because of a future spec that is not even finished and that no browser in the world is currently able to fulfill? I say the attributes don't need to be removed. They work everywhere. They will work everywhere for the next 10 years or more. I say it's stupid to "fix" something that is *not* broken. Especially if the *only* thing this "fix" does is to actually *break* something. Basically you say there is no other way than to stick to a unfinished spec no matter if it makes sense or not. Like it's a law and not a recommendation. I'm not a lawyer. I'm a coder. You say you need to remove "invalid" attributes from the output. But at the same time you are accepting the *same* invalid attributes as input? This is confusing. When I use an align attribute in my code I expect it to work according to the spec. Like it did for many years. Now you introduced your own spec where it started to *not* work in some cases. This is confusing as hell. Till last week it was *my* decision what my code did. Now *you* decide that the same code is invalid in some cases but still valid in other cases. You *dropped* a feature. Why? Where is the documentation for this? Where was the "consider changing your templates" warning a year ago? Where is the discussion were the community decided to removed this part of the WikiText feature set? Why only this part? Why not simply remove all of the invalid stuff? Why not the garbage? This would be way less confusing. A lot of stuff will break but everybody would *know* why. Even people that were not involved in the discussion. And you *need* to remove all invalid stuff some day. When will this happen? In 10 years? The same time when the browsers will stop to read the align attributes? If this is true why not simply let the browsers decide if they are fine with an align attribute or not? Why do you think it's your responsibility to make this decision? It wasn't your responsibility till last week. All you did was whitelisting. The align attributes were copied to the output or not. Simple. What you are doing now is to *guess* the meaning of these attributes and to replace it with something else that may or may not have the same meaning. It's not your responsibility to change the meaning of my code. All the current hack does is to add confusion. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40329] Don't use hacks to replicate a browser function, either let align="" pass through or not; in HTML5
https://bugzilla.wikimedia.org/show_bug.cgi?id=40329
--- Comment #25 from Daniel Friesen
2012-09-27 21:26:03 UTC ---
(In reply to comment #24)
> I have no idea who Strawman is.
Not who, what. It's a type of logical fallacy.
Here's a pretty good description of it:
http://yourlogicalfallacyis.com/strawman
> You say the align attributes need to be removed from the HTML output. I don't
> see why this needs to be done *now*. Because of a future spec that is not even
> finished and that no browser in the world is currently able to fulfill? I say
> the attributes don't need to be removed. They work everywhere. They will work
> everywhere for the next 10 years or more. I say it's stupid to "fix" something
> that is *not* broken. Especially if the *only* thing this "fix" does is to
> actually *break* something.
>
> Basically you say there is no other way than to stick to a unfinished spec no
> matter if it makes sense or not.
I think I'll make this a bullet-pointed list:
- HTML5 (or as WHATWG calls it "HTML") is a living standard. Completion of the
standard is irrelevant. Individual components of the spec are separate. Some
components are new and in flux, while others are stable and finished
standardization. Removal of presentational attributes is one of those. align is
no longer a standard attribute, that is finished standardization.
- The facts people used to misrepresent to say that HTML5 isn't ready are also
not valid anymore:
http://wiki.whatwg.org/wiki/FAQ#What.27s_this_I_hear_about_2022.3F
- Additionally align="" has been deprecated since HTML 4.0. Even if you ignore
current standards and try to use the previous obsolete standards these still
aren't attributes we're supposed to be outputting from our software.
- We use HTML5. This whole discussion about whether HTML5 is finished or not is
pointless. HTML5 is the standard we are using RIGHT NOW to output MediaWiki
markup. Whether something is valid or invalid in a spec we are not using is
irrelevant.
> Like it's a law and not a recommendation.
>
> I'm not a lawyer. I'm a coder.
>
> You say you need to remove "invalid" attributes from the output. But at the
> same time you are accepting the *same* invalid attributes as input? This is
> confusing. When I use an align attribute in my code I expect it to work
> according to the spec. Like it did for many years. Now you introduced your own
> spec where it started to *not* work in some cases. This is confusing as hell.
> Till last week it was *my* decision what my code did. Now *you* decide that
> the
> same code is invalid in some cases but still valid in other cases.
WikiText is not HTML, that's a simple fact you'll have to understand. HTML is
consumed by browsers and it's format is defined by the HTML standard. While
WikiText is consumed (and written) by the MediaWiki parser and human users who
do not follow standards. For a user trying to insert a centered table in the
middle of the page {| align=center makes perfect sense to create a centered
table even though is the wrong way to do it in HTML (which they probably won't
know). So it makes perfect sense to take that as an indication to create a
centered table. Which in CSS means to apply style="margin-left: 0;
margin-right: 0;" as we do now.
> You *dropped* a feature. Why? Where is the documentation for this?
> Where was the "consider changing your templates" warning a year ago?
> Where is the discussion were the community decided to removed this part of
> the WikiText feature set?
As with everything we change 1.19's RELEASE-NOTES included the introduction of
presentational attribute sanitization.
At the time of introduction neither the nor nested block quirks were
known so there was no need for any mass notification about incompatibilities
since it was supposed to be compatible.
The table float bug was caused by the relevant info being buried in a separate
section of the spec. After the table float bug was discovered someone tried
fixing it. Which caused bug 40306 since the committer made a mistake and made
that special case apply to more than the one tag it applies to. Then recently
that bug got fixed and deployed. Now the one single remaining issue is the
nested block align quirk.
;) Btw, here's a fun fact. HTML4 does not even appear to specify that
behaviour. In fact it has examples using text-align as a replacement for align.
It's been discussed on the mailing list multiple times. But we don't go asking
for community approval for each and every single change we make for the
software. It's ridiculously unscalable. Nothing would get done.
> Why only this part? Why not simply remove all of the invalid stuff? Why not
> the
> garbage? This would be way less confusing. A lot of stuff will break
> but everybody would *know* why. Even people that were not involved in the
> discussion.
Right now the Sanitizer only supports attribute sanitization. We don't have a
way to sanitize whole elements yet. To do that we need to add a new sanitizer
api f
[Bug 40329] Don't use hacks to replicate a browser function, either let align="" pass through or not; in HTML5
https://bugzilla.wikimedia.org/show_bug.cgi?id=40329 --- Comment #26 from TMg 2012-09-28 12:07:33 UTC --- (In reply to comment #25) > We use HTML5. No, you don't. You still output out-dated garbage like and . I consider a single or tag a *lot* more dangerous than thousands of align attributes. I wouldn't be here if your decision would make sense. But it does not. As long as you do *not* output valid HTML5 all of your arguments are irrelevant. As long as you output tags there is no reason to not output align attributes. Simple. Dropping a few random snippets for being "invalid" and breaking them the same time is just lazy. All it does is adding confusion. I think I said that multiple times now. > WikiText is not HTML No, that's not true and you know it. Things like tags or class attributes are simply whitelisted in the MediaWiki parser. When I write something like it actually *is* HTML. When I wrote align="center" in a template it actually was HTML till last week. Now it's not HTML any more. Instead it has a special meaning in WikiText. Since last week it became *different* from what it was the week before. What you did was simply dropping a feature. Instead you are outputting something that may or may not be intended by the template developer. Dropping a feature requires community consensus. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40329] Don't use hacks to replicate a browser function, either let align="" pass through or not; in HTML5
https://bugzilla.wikimedia.org/show_bug.cgi?id=40329
--- Comment #27 from Daniel Friesen
2012-09-28 17:39:24 UTC ---
(In reply to comment #26)
> (In reply to comment #25)
> > We use HTML5.
>
> No, you don't. You still output out-dated garbage like and . I
> consider a single or tag a *lot* more dangerous than thousands
> of align attributes.
>
> I wouldn't be here if your decision would make sense. But it does not. As long
> as you do *not* output valid HTML5 all of your arguments are irrelevant.
>
> As long as you output tags there is no reason to not output align
> attributes.
Those are bugs, and they should be fixed. The project of fixing invalid markup
not being finished is NOT a valid reason to say that invalid markup should not
be fixed. That's circular reasoning. When you have two bugs and you fix one.
You work towards fixing the other. You don't re-introduce the first bug because
the second one has not been fixed.
Frankly if I had the time, I'd just go and fix that bug right now.
And yes we do use HTML5. We output HTML5 doctypes. We follow HTML5 markup
rules. We support HTML5 elements, attributes, and features. And we have an open
tracking bug tracking issues with our HTML5 output that should be fixed. Just
because we have a bug or two that needs fixing does not mean we're not using
HTML5. Rather the fact that we actually consider those bugs is an indication
HTML5 is our target.
> Simple.
>
> Dropping a few random snippets for being "invalid" and breaking them the same
> time is just lazy. All it does is adding confusion. I think I said that
> multiple times now.
Then instead of crusading with ridiculous arguments like saying we're not using
HTML5 and HTML5 is unfinished and shouldn't be used try pushing for the
non-lazy way to fix invalid html.
There have been different ideas on the mailing list. Some ideas how we might
fix the block alignment. Others on ways we might eliminate use of deprecated
attributes in the long run. The discussion on how to deal with invalid markup
in the long run doesn't even appear to have closed.
> > WikiText is not HTML
>
> No, that's not true and you know it. Things like tags or class
> attributes are simply whitelisted in the MediaWiki parser. When I write
> something like it actually *is* HTML. When I wrote align="center" in a
> template it actually was HTML till last week.
>
> Now it's not HTML any more. Instead it has a special meaning in WikiText.
> Since
> last week it became *different* from what it was the week before.
WikiText is not HTML. WikiText is a loose page authoring syntax. We take in
text that people write using simple patterns and try to format the text using
the best output HTML we can. Starting a line with * is a good way to make an
unordered list, so we turn those into 's. [[Foo]] is a good way to make
a link so we turn those into . Likewise {| makes a good syntax for tables.
Some people want to output certain HTML elements into their pages. Such as a
HTML . And others want to output a in ways we can't do with * syntax.
We can't really cover all the ways to do something using some other syntax. So
for the WikiText we support to output those HTML elements we support a subset
of the same syntax HTML uses to output them. So while it's a simila format,
that's WikiText, not HTML.
> What you did was simply dropping a feature. Instead you are outputting
> something that may or may not be intended by the template developer.
>
> Dropping a feature requires community consensus.
As I mentioned before from the very start this was supposed to be a working
translation from dropped html to css. The fact the visual look of the output
would change was not known. Because it did not change when the feature was
first tested. It only changed in edge cases that were not known. Invalid markup
in the output is not a feature. There was no feature being dropped.
The issues only came out later as bugs. And not just later, they were not
pointed out until after 1.19 was already released. Even though this change
should have already been live on the various Wikipedias and all their thousands
of templates with syntaxes all over the place.
A few things you may have missed:
- CSS translation functionality is controlled by
$wgCleanupPresentationalAttributes. It can be controlled per-wiki.
- And we actually in fact have had people requesting this feature. So this
feature definitely isn't going away entirely.
- MediaWiki defaults are not based on WMF setup. ie: We have settings where we
add them. Set one default in MediaWiki, and use a different value on WMF's
wikis.
- What you should really be pushing for is not removal of this. But setting
$wgCleanupPresentationalAttributes either as a mw default (if 3rd party wikis
are your concern) or as a site request (if this is affecting WMF wiki). Though
if you're going to do the latter please open a separate bug since this one is a
little to generically technical.
- How to handle invalid markup both short-ter
[Bug 40329] Don't use hacks to replicate a browser function, either let align="" pass through or not; in HTML5
https://bugzilla.wikimedia.org/show_bug.cgi?id=40329 MZMcBride changed: What|Removed |Added CC||b...@mzmcbride.com --- Comment #28 from MZMcBride 2012-09-29 16:10:10 UTC --- (In reply to comment #27) > Then instead of crusading with ridiculous arguments like saying we're not > using > HTML5 and HTML5 is unfinished and shouldn't be used try pushing for the > non-lazy way to fix invalid html. I think this is fair. I'm inclined to file two bugs here: (1) Kill $wgCleanupPresentationalAttributes from MediaWiki core; "magical" transformations like this are almost always an absolutely terrible idea and should only be done when absolutely necessary (such as stripping out dangerous attributes); you're never going to catch every (edge) case and you're going to do more harm than good (and create confusion about what's magically transformed and under what conditions); I thought we established these principles with magical transformations years ago. (2) Add a tracking category for pages using invalid HTML5; this should be straightforward enough; allow wiki authors to slowly fix these pages to use better code by auto-categorizing pages that use invalid HTML5. This bug can then rot, as far as I'm concerned. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40329] Don't use hacks to replicate a browser function, either let align="" pass through or not; in HTML5
https://bugzilla.wikimedia.org/show_bug.cgi?id=40329 --- Comment #29 from Daniel Friesen 2012-09-29 16:47:42 UTC --- (In reply to comment #28) > (In reply to comment #27) > > Then instead of crusading with ridiculous arguments like saying we're not > > using > > HTML5 and HTML5 is unfinished and shouldn't be used try pushing for the > > non-lazy way to fix invalid html. > > I think this is fair. I'm inclined to file two bugs here: > > (1) Kill $wgCleanupPresentationalAttributes from MediaWiki core; "magical" > transformations like this are almost always an absolutely terrible idea and > should only be done when absolutely necessary (such as stripping out dangerous > attributes); you're never going to catch every (edge) case and you're going to > do more harm than good (and create confusion about what's magically > transformed > and under what conditions); I thought we established these principles with > magical transformations years ago. What do you think of a new setting to disable all these invalid tags and attributes. Defaulting it on and having WMF and existing wikis turn it off. So that on new wikis it won't even be supported from the start? > (2) Add a tracking category for pages using invalid HTML5; this should be > straightforward enough; allow wiki authors to slowly fix these pages to use > better code by auto-categorizing pages that use invalid HTML5. > > This bug can then rot, as far as I'm concerned. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40329] Don't use hacks to replicate a browser function, either let align="" pass through or not; in HTML5
https://bugzilla.wikimedia.org/show_bug.cgi?id=40329
Krinkle changed:
What|Removed |Added
CC||krinklem...@gmail.com
--- Comment #30 from Krinkle 2012-09-29 22:06:52 UTC ---
Okay, lets try to get this thing back on track and work out some realistic
goals. 1.20 release is coming up soon.
* $wgCleanupPresentationalAttributes will be removed from core (master and
REL1_20), it is currently broken and to be considered an unacceptable
regression.
* As for the future (whether or not working on improving it and brining it
back). Changing the output of custom wikitext markup (e.g. changing the
wikitext table syntax {| output to create sections) is one thing.
Though that is still something to be very cautious about, it can be useful.
However changing the output of simple HTML is quite another.
Changing that must never exceed the boundaries of security and normalization.
Anything else is imho by definition a bad idea. Trying to extract the meaning
of html attributes in an automated fashion to try and update it is a lost
cause. Not only will it cause confusion (do we support it or not? And if so,
why are we fixing unsupported stuff? Are we going to auto-migrate everything
that has been be deprecated in some a W3C HTML specification? Then we'll have
to migrate HTML3.2 bgcolor="" as well (deprecated in HTML4.01).
Aside from being confusing, it can also cause bugs because we're changing
markup. That means that certain CSS selectors may no longer apply (`.foo center
.whatever { color: pink; }`). Or certain JavaScript modules will start failing
in weird unexpected ways (firstChild.nextNode.nodeName.toLowerCase() ===
'center'), or the layout will change due to the difference in css weight
between inline styles and deprecated attributes (or placeholder classes we
would substitute) and in which order they would merge if we try to fix them.
And the list of possible problems goes on.
Now if there was actually some kind of victory at the end of this quest, it
could be worth pursuing. But surely we don't consider passing the HTML5
validator a victory? All browsers we support support these attributes, they
likely do so because old document (or old habits) die hard and they will be
served through newer software frameworks. This all works just fine and there is
nothing to be concerned about. The validator is a tool, no more no less. It is
not a browser and we don't have to support it.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40329] Don't use hacks to replicate a browser function, either let align="" pass through or not; in HTML5
https://bugzilla.wikimedia.org/show_bug.cgi?id=40329
--- Comment #31 from Krinkle 2012-09-29 22:09:56 UTC ---
Okay, lets try to get this thing back on track and work out some realistic
goals. 1.20 release is coming up soon.
* $wgCleanupPresentationalAttributes will be removed from core (master and
REL1_20), it is currently broken and to be considered an unacceptable
regression.
* As for the future (whether or not working on improving it and bringing it
back). Changing the output of custom wikitext markup (e.g. changing the
wikitext table syntax {| output to create sections) is one thing.
Though that is still something to be very cautious about, it can be useful.
However changing the output of simple HTML is quite another.
Changing that must never exceed the boundaries of security and normalization.
Anything else is imho by definition a bad idea. Trying to extract the meaning
of html attributes in an automated fashion to try and update it is a lost
cause. Not only will it cause confusion (do we support it or not? And if so,
why are we fixing unsupported stuff? Are we going to auto-migrate everything
that has been be deprecated in some W3C HTML specification? Then we'll have
to migrate HTML3.2 bgcolor="" as well (deprecated in HTML4.01).
Aside from being confusing, it can also cause bugs because we're changing
markup. That means that certain CSS selectors may no longer apply (`.foo center
.whatever { color: pink; }`). Or certain JavaScript modules will start failing
in weird unexpected ways (firstChild.nextNode.nodeName.toLowerCase() ===
'center'), or the layout will change due to the difference in weight of css
rules.
Weight of inline styles vs. deprecated attributes vs. placeholder classes we
may substitute. As well as in which order they would merge if we try to fix
them.
And the list of possible problems goes on.
Now if there was actually some kind of victory at the end of this quest, it
could be worth pursuing. But surely we don't consider passing the HTML5
validator a victory? All browsers we support support these attributes, they
likely do so because old documents (and old habits) die hard and they will be
served through newer software frameworks. This all works just fine and there is
nothing to be concerned about. The validator is a tool, no more no less. It is
not a browser and we don't have to support it everything it says.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40329] Don't use hacks to replicate a browser function, either let align="" pass through or not; in HTML5
https://bugzilla.wikimedia.org/show_bug.cgi?id=40329
--- Comment #32 from MZMcBride 2012-09-30 02:06:56 UTC ---
(In reply to comment #31)
> * $wgCleanupPresentationalAttributes will be removed from core (master and
> REL1_20), it is currently broken and to be considered an unacceptable
> regression.
I've split this out to bug 40632 ("Kill $wgCleanupPresentationalAttributes from
MediaWiki core").
> Now if there was actually some kind of victory at the end of this quest, it
> could be worth pursuing. But surely we don't consider passing the HTML5
> validator a victory? All browsers we support support these attributes, they
> likely do so because old documents (and old habits) die hard and they will be
> served through newer software frameworks. This all works just fine and there
> is
> nothing to be concerned about. The validator is a tool, no more no less. It is
> not a browser and we don't have to support it everything it says.
I've split this out to bug 40633 ("Auto-categorize pages that contain invalid
HTML"). I believe, if possible, auto-categorizing pages that contain invalid
HTML (attributes or elements) would be beneficial to wiki editors. Knowledge is
power, or something.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40329] Don't use hacks to replicate a browser function, either let align="" pass through or not; in HTML5
https://bugzilla.wikimedia.org/show_bug.cgi?id=40329 Krinkle changed: What|Removed |Added Priority|Unprioritized |Normal Version|1.20.0beta0 |1.20-git Target Milestone|--- |Future release Severity|normal |enhancement --- Comment #33 from Krinkle 2012-10-01 21:38:18 UTC --- Lowering priority of this bug in favour of bug 40632. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40329] Don't use hacks to replicate a browser function, either let align="" pass through or not; in HTML5
https://bugzilla.wikimedia.org/show_bug.cgi?id=40329 Erwin Dokter changed: What|Removed |Added See Also||https://bugzilla.wikimedia. ||org/show_bug.cgi?id=66413 -- You are receiving this mail because: You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
