Talk:el Bulli

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia


Reverting image layout[edit]

The previous edit, using {{clear}} forced large gaps in the text at 800x600 and wider, similar to the "stack-up" effect, going against Wikipedia:Picture_tutorial#Avoiding_stack-ups. More text would be nice to have, but until then, the text should flow smoothly. This layout allows both text and images to flow down the page evenly, and works for both narrow and wide screens. --Lexein (talk) 22:54, 16 September 2010 (UTC)[reply]

Except that it actually doesn't. At larger resolutions, the image layout that I fixed would cause edit links to bunch up and/or be hidden and the pictures to do exactly what you are complaining about with stacking. Forcing sections to clear prevents that from happening. Yes, it introduces more whitespace at some resolutions, but it makes seeing the edit links much simpler at all resolutions (which is a good thing, outweighing minor whitespace problems). Given that at certain resolutions your layout actually hides all the editsection links, your layout is unintentionally bad, making it harder for people to edit. I have, accordingly, reverted. Sorry to be reverting you like that, but the ability of people to easily edit the page overrides minor cosmetic concerns. → ROUX  07:12, 17 September 2010 (UTC)[reply]
  1. The following testing, already agreed-upon guidelines, and easy configuration changes do not support your assertions.
  2. In the interest of seriously addressing your concerns, I tested for bunching or covering using this copy (of 385297327 my last edit), so the edit links would appear.
    Tested as an IP user, and logged in with my username.
    Tested with Firefox 3.6.10, Opera 10.61, Safari 5.02, IE 8.0.6001.18702, and Chrome 6.0.472.59 on WinXP Pro SP3.
    Also tested Firefox 3.6.10, Opera 10.61, Safari 5.0.2 and Camino 2.0.4 on OS X 10.5.8.
    Also tested Firefox 3.6.10, Opera 10.60 on Ubuntu 9.04.
    No bunching or covering occurred at any window width from 300px to 1280px and beyond. At <350px everything on the right side starts to be hidden by the right window edge, due to fixed elements in the CSS, not wiki layout. At no point did edit links tightly group together, nor were they covered over (made invisible or unclickable) by any other elements. If you meant something else, please elucidate.
  3. With the {{clear}}s, at 1000px wide and up to a reasonable maximum of 1680px (a 20" LCD), the white space grows quite absurdly large. Compare with a FA such as San Francisco, or any other with many images.
  4. Layout forcing with clear is a good thing for large articles with plenty of text, but it's not appropriate for this smallish article yet. Examination of WP:Good articles and WP:Featured articles, will show no gaping whitespace (except TOC), at a broad range of screen widths, from 800px to 1280px and even 1680px. Of course, that's partially because GA and FA simply have more text. Until there's more text, though, clear is not a good fit.
  5. I think WP is concerned with RS text first, images second, and individual display options third. A layout which only hangs together at small window sizes is no better than a layout which, as you say, hides links or bunches up. Large blank areas go against MOS, full stop. Personal browser choice and preferences settings cannot override MOS guidelines about excess whitespace.
  6. Shrinking images is not an appropriate way to control white space in an article. If an image is important and good enough to be in an article, it should be at a size to be immediately recognizable. In your edit, the gallery and thumbs are too small. There's broad consensus already established that images should be between 200px and 300px wide, for best viewing in the widest range of screen widths. Small article size does not justify shrinking images.
  7. Perhaps the article should have fewer sections. Short intro, longer article, no need for so many edit links.
  8. Perhaps you would prefer the [edit] link not to move around as the page is resized; see the next point below.
  9. If you must use a browser which exhibits bunching or covering of edit links on the right-hand side of the page, give yourself a break and move the edit links next to the section headers with
    Preferences/Gadgets/User interface gadgets: editing, Moves edit links next to the section headers (documentation).
    And flush your browser cache. And shift-refresh.
--Lexein (talk) 17:27, 17 September 2010 (UTC)[reply]
Well you're being dishonest in at least one point there, so I'm not sure what the purpose of this discussion is. At 1280x1024, for example, in fully updated FF, the edit links are indeed obscured. MOS is trumped by accessibility issues, period. Whitespace is purely cosmetic and therefore unimportant when it comes to ability of people to easily edit the page. Period. The gallery was merely an error; I had a long night at the restaurant and forgot to increase the size from the example template given. → ROUX  18:33, 17 September 2010 (UTC)[reply]
ebL Firefox 3.6.10 WinXP 1680x1050 - no hiding, obscuring, or inaccessibility.
A. Stop being WP:UNCIVIL. WP:BRD does not excuse incivility. Your choice of job does not excuse incivility, or a failure to WP:Assume good faith. I am scrupulously honest, full stop.
B. The purpose of this discussion is to try to improve the article by either eliminating interference with the text flow of El Bulli and/or to come to some accomodation such as 7, 8, 9 above.
C. The simple, demonstrable fact is that no [edit] tags were ever hidden, "obscured" or inaccessible in any of my tests, see the screenshot. There's a Vimeo video at http://vimeo.com/15068114 which at 01:16, 18 September 2010 (UTC) is currently in the queue to be rendered. I have no idea if it will show the detail of the rendering of edit links, but I hope it will. Failed conversion. awesome.--02:00, 18 September 2010 (UTC)
D. Some "bunching" occurred, but that cannot be deemed an accessibility issue, by the strict definition of being unfindable, covered by another element, or unclickable. There is no verifiable accessibility issue here. WP:JUSTDONTLIKEIT does not equate to an accessibility issue, and cannot trump MOS.
E. Feel free to post a screenshot of your experience somewhere.
--Lexein (talk) 01:16, 18 September 2010 (UTC)[reply]
Saying you were dishonest is not incivil. It is fact. My choice of job is why I missed changing the image size in the gallery. You will note that, in fact, I stated that quite clearly and did not say anything else about it. [1], by the way. → ROUX  19:12, 18 September 2010 (UTC)[reply]
If you reread with care the first sentence of point "2.", you may see your error, and the reason there is absolutely no dishonesty whatsoever on my part, and that your rationale for accusing me (repeatedly!) is utterly false, and a violation of WP:CIVIL and WP:AGF:
"...I tested for bunching or covering using this copy (of 385297327 my last edit), so the edit links would appear."
Don't see it yet? Here it is: directly viewing any diff or oldid page hides the edit links, as in the oldid page used in your screenshot, and (OMG!) your diff 385 and oldid 385. This is why I copied 385297327 my last edit oldid page to a new page in my userspace for testing (compare the wiki sources!). My honesty is above reproach.
The main point here is that my tests are valid, and show that edit links are not hidden, obscured, or inaccessible by non-cleared image positioning at any window width from 350px to 1680px, only by viewing oldids or diffs. --Lexein (talk) 22:28, 18 September 2010 (UTC)[reply]

Third opinion: I'm currently testing in 1280x800, and the current version (with the clear templates) looks fine to me. I actually prefer the current version to this version, as the images seem to work better with the text. Rather than just being a pile of images, there's organization: here are the front and rear entrances together, for example. For the record, I can see edit links on both pages, though it's true that if you have images bunched up then they can be obscured. I'm not entirely convinced that MOS trumps accessibility; if nothing else, having [edit] [edit] [edit] piled up next to an image just looks messy and marginally unprofessional. — HelloAnnyong (say whaaat?!) 15:28, 20 September 2010 (UTC)[reply]

1 Thank you for the 3O. I'm responding to make sure there is no misunderstanding of my position. The current version is indeed different from the "copy" version, in that I did not chase Roux's gallery edit. I do like the gallery when properly sized, as it is now. I do like clears in large articles, just not here because:
2 The excess white space, in wide windows or when the TOC is collapsed, does not belong there. GA and FA do not have this, by and large, as I said, because they have more text. Text flows, and it should be allowed to do so. That was the main thrust of my argument, that clears belong in articles with sufficient text, but not here, yet.
3 The edit links are visible on "copy", on the screenshot of "this copy" (above right), and on the current edit, because those are all top of history pages. The edit links disappear whenever you view a history page (oldid) or diff.
4 Please be very careful and specific in your language about the word "obscured." If the images are bunched up so that the edit links are pushed down out of the window, that's one thing, but does that count as "obscured"? I don't think so. The edit links flow just like text. Is that what you meant by "obscured"? I never saw any evidence of edit links being covered, hidden, or in any way unclickable or inaccessible. Please, in what browser/versionm, and exactly what width, were the links ever covered, hidden, unclickable, or in any way inaccessible?
--Lexein (talk) 16:46, 20 September 2010 (UTC)[reply]
You're right, I was unclear by using 'obscured'. I meant when they get pushed down the window. Anyway, "that clears belong in articles with sufficient text" isn't categorically true; for example, I've added it to articles where there's been an image on the right, and there's a two-column References section beneath, but that section gets squished so that it doesn't take up the full width of the page due to the image. That was a terrible description, but hopefully you get what I'm saying. You can see this for yourself on this page if you move Image:ElBulliKitchen.jpg into the Closure section and see what happens to the refs.
As I stated before, I still prefer the current version because the images are organized in a more logical manner than just throwing them all down the right side of the page. In this way they serve to enhance the text more. — HelloAnnyong (say whaaat?!) 19:09, 20 September 2010 (UTC)[reply]

Reason for closing[edit]

According to this article: http://shine.yahoo.com/channel/food/quot-worlds-best-restaurant-quot-el-bulli-set-to-close-2517443/ ; despite the red ink, the place was closing for other reasons.Kdammers (talk) 05:04, 30 July 2011 (UTC)[reply]